4 ms·
I find this particular NIST process confusing. ML-KEM 1024 for key encapsulation is FIPS 203 certified, so I take it that it is the right choice for key encapsu
by jonathanstrange 2y ago
I find this particular NIST process confusing. ML-KEM 1024 for key encapsulation is FIPS 203 certified, so I take it that it is the right choice for key encapsulation? But there are FIPS 204 and 205 standards for digital signatures, apparently soon to be complemented by FIPS 206 based on FALCON. Which one should be used?
Has NIST stopped to recommend one winner and opted for several. Or, do these have different purposes?
- less_less 2y agoSLH-DSA aka SPHINCS+ is the most conservative choice (i.e. they are all secure against currently-known attacks, but SLH-DSA is less likely to be broken later), but it is slow (at least several milliseconds to sign) and produces large sigs (>= 7.8kB). This means that it may not be suitable for all applications. Dilithium is faster but less conservative, harder to implement securely, and produces medium sigs. FALCON is even harder to implement securely, faster to verify and produces smaller sigs, though still much larger than classical systems. IMHO this choice was questionable, in that its advantages overlap too heavily with Dilithium to be worth another standard, but NIST apparently felt otherwise.
- jonathanstrange 2y agoThank you! That clarifies it. The length of the signatures indeed seems to be a problem. I'm currently investigating ways to implement secure group chat (like adapting MLS to use PQC).