John Mattsson writes: > NIST does not deserve any criticism for continuing to evaluate SIKE.
The NIST actions that I quoted go far beyond "continuing to evaluate SIKE". NIST explicitly pointed to SIKE as part of its official rationale for throwing away FrodoKEM and delaying a decision on Classic McEliece. NIST flatly denied the impact of an important line of SIKE attacks. NIST said SIKE was attractive because of its small key and ciphertext sizes. NIST said it intended to standardize _some_ KEM not based on structured lattices; NIST selected SIKE as one of just a few options for that. NIST's main complaint about SIKE was about the CPU time used---"SIKE encapsulation and decapsulation take on the order of tens of millions of cycles, which is still relatively slow compared to other post-quantum schemes"---but SIKE was affordable in the Google-Cloudflare experiment, was continuing to find speedups, was already down to 8 million cycles on Intel's Alder Lake CPUs, and was within striking range of BIKE and HQC in Figure 10 of NIST's report. For people imagining that NIST's post-quantum selection procedures reduce the risk to such low levels that the risk can be ignored: How exactly is that supposed to work? Why is the SIKE example not enough evidence that it _doesn't_ work? > D. J. Bernstein wrote: > > as far as I know there was only one other cryptographer on record > > recommending against using SIKE. [ ... ] > NSA NSA in 2021 telling people to wait for post-quantum standards is not a "cryptographer on record recommending against using SIKE". https://www.youtube.com/watch?v=q6vnfytS51w is a talk that Tanja Lange and I gave in 2018. At minute 48 she says the following: There's some hope it will remain unbroken until next year. But, well, I'm not sure yet where I'll put my money. At this moment I think actually CSIDH has a better chance than SIKE of surviving, but who knows. Don't use it for anything yet. This is a very clear warning not just about CSIDH (which she coauthored) but also about SIKE. My own public warning in 2021 was also evaluating SIKE (https://twitter.com/hashbreaker/status/1387779717370048518): Agreeing with main points in 3, 4, 6, 10 in https://eprint.iacr.org/2021/543. More objections to 2, 5, 7, 9. Most important dispute is regarding risk management, 1+8. Recent advances in torsion-point attacks have killed a huge part of the SIKE parameter space, far worse than MOV vs ECDLP. For comparison, here's context you omitted from the 2021 NSA quote: Once NIST post-quantum cryptographic standards are published and certification procedures for those algorithms are established, CNSSP-15 will be updated with a timeline for required use of the post-quantum algorithms and disuse of the quantum-vulnerable portion of the current CNSA Suite of algorithms. The nature of this timeline will depend upon the standards selected and the ability of the market to provide supporting products. NSS customers are reminded that NSA does _not_ recommend and policy does not allow implementing or using unapproved, non-standard or experimental cryptographic algorithms. This isn't saying anything about any particular cryptographic algorithm: it's a generic please-don't-roll-out-post-quantum-crypto-yet. There's also no cryptographer named as an author. > I think it is very sad that deploying a lot of non-standard and > experimental cryptographic algorithms gives a lot of positive media > attention⦠People rolling out post-quantum encryption as quickly as possible are at least _trying_ to solve the problem of today's user data being recorded by attackers and decrypted with future quantum computers. If you have a rational argument for simply giving away today's user data to attackers, please lay out the argument without using emotion-laden language. People adding this encryption as a second layer on top of the existing encryption layer (typically X25519), rather than throwing away the existing layer, are limiting the damage if the post-quantum encryption turns out to be breakable. This has negligible cost. > you according to this paper donât agree that If you have a question about something I wrote, please quote it and ask the question. ---D. J. Bernstein
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
