3 ms·
Here is the documentation: https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf All 15 the fol
by dependenttypes 6y ago
Here is the documentation: https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf
All 15 the following are moving to the 3rd round.
Third-Round Finalists:
Public-Key Encryption/KEMs
- Classic McEliece (Code)
- CRYSTALS-KYBER (Lattice)
- NTRU (Lattice)
- SABER (Lattice)
Digital Signatures
- CRYSTALS-DILITHIUM (Lattice)
- FALCON (Lattice)
- Rainbow (Multivariate)
Alternate Candidates:
Public-Key Encryption/KEMs
- BIKE (Code)
- FrodoKEM (Lattice)
- HQC (Code)
- NTRU Prime (Lattice)
- SIKE (Supersingular Elliptic Curve Isogeny)
Digital Signatures:
- GeMSS (Multivariate)
- Picnic (Zero-knowledge)
- SPHINCS+ (Hash)
All of Bernstein's submissions (except the joke one) are in the finalist or in the alternative list.
A note regarding the alternatives:
> The alternate candidates are regarded as potential candidates for future standardization, most likely after another round of evaluation. Some of the alternate candidates have worse performance than the finalists but might be selected for standardization based on NIST’s high confidence in their security. Others have acceptable performance but require additional analysis or other work to inspire sufficient confidence in their security for NIST to standardize. In addition, some alternate candidates were selected based either on NIST’s desire for diversity in future post-quantum security standards or on their potential for further improvement.
I am quite a big fan of SPHINCS+, Picnic (these two reduce their security to the one of their underlying hash functions), and Classic McEliece myself. SIKE is interesting too but as far as I know it needs to be used interactively. Rainbow is also interesting.
- hackcasual 6y agoThe problem with classic mceliece is the size of the public keys, which is measured in megabytes
- dependenttypes 6y ago1.3 MiB for the most secure parameter set (mceliece8192128). The other sets are less than 1 MiB.
- sgillen 6y agoWell, at least people are used to downloading Mb of junk when they browse the internet these days anyway...
- hackcasual 6y agoWe also want crypto systems that work on embedded/constrained environments
- dependenttypes 6y agoAnd that's fine. These systems can use NTRU or whatever else. These systems being weak is not a reason to drag everyone else down.
- sgillen 6y agoYeah I’m not actually stoked on big keys, just being snarky.
- skissane 6y ago> All of Bernstein's submissions (except the joke one) are in the finalist or in the alternative list. What was the joke one?
- rainworld 6y agoPost-quantum RSA, 1-terabyte keys: https://eprint.iacr.org/2017/351.pdf https://eprint.iacr.org/2017/351.pdf
- dependenttypes 6y agoNote, the submission was a joke and the paper was humorous but not a joke itself. It presents a new factorization method for example.
- nullc 6y agoI think McEliece and Sphincs+ are both excellent applications for typical PGP use cases-- and have great security properties. Their weaknesses don't matter as much in low throughput applications. (e.g. McEliece's slow key generation is a big problem when you're creating 1000 connections per second and want good perfect forward secrecy. It's a non-issue for a long term key that is rotated at most once a year.) I'm sad that sphincs+ is only an alternate. Things like software signing and human scale communication don't care if signing is somewhat slow and the signatures are long-- but they do have extremely long lived keys that are difficult to rotate.
- dependenttypes 6y agoSigning/verification speed are both important on things like TLS/SSH/etc and sadly SPHINCS+ can not compete in either, see page 55 in https://sphincs.org/data/sphincs+-round2-specification.pdf https://sphincs.org/data/sphincs+-round2-specification.pdf But I agree that it can be used in the OpenPGP use-case. Anyway, Rainbow seems quite solid for TLS. > McEliece's slow key generation is a big problem when you're creating 1000 connections per second and want good perfect forward secrecy I personally think that if you want forward secrecy you should derive the session key from both the static McEliece key and the ephemeral ntru/whatever key.
- nullc 6y agoSSH probably could use a much simpler hash based signature than sphincs+ -- e.g. you wouldn't really care if the signature (which is just sent once at connection time) was 40kbytes. Nothing in the competition does that. (too bad, because it would also be the fastest algo in the competition to verify and one of the fastest to sign).