Sophie Schmieg writes:
> [1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
I see that you're arguing that the ML-KEM spec is too rigid to allow a
Dual EC-style secretly keyed backdoor, i.e.., that the entropy needed
for the backdoor key wouldn't be able to fit into the spec.
Was someone arguing the opposite? You write "the concerns about it are
overblown"; can you please quote the concerns that you're disputing?
I've noticed other cryptosystems that don't seem to have many knobs to
play with in the spec. For example, the starting SIKE curve was chosen
to be very concise, to remove any concern about a backdoored choice of
curve. And yet a few cryptographers, including me, were on record by
2021 stating concerns about SIKE having not been studied enough. Would
you describe the apparent rigidity of SIKE as evidence that our concerns
were overblown and that SIKE is secure? If not, why not? How exactly is
this different from what you're now arguing about ML-KEM?
RSA-512 is a well-known cryptosystem that has been applied to large
quantities of user data. The specification of RSA-512 seems reasonably
rigid. Would you describe this rigidity as evidence that RSA-512 is
secure and that concerns about RSA-512's security are overblown? If not,
why not?
FrodoKEM, which is widely portrayed as the most conservative lattice
system, says in
https://web.archive.org/web/20230224071445/https://frodokem.org/files/FrodoKEM-sp
ecification-20210604.pdf
that it's an "instantiation and implementation" of a 2010 paper:
https://web.archive.org/web/20111206143256/https://eprint.iacr.org/2010/613.pdf
That paper proposes a lattice-based cryptosystem, and concretely
proposes using lattice dimension 256 for security "about" 2^150 and "at
least" 2^128. This is another concisely defined cryptosystem with very
few obvious knobs to turn. Would you describe this rigidity as evidence
that this dimension-256 lattice-based cryptosystem is secure and that
concerns about its security are overblown? If not, why not?
---D. J. Bernstein
===== NOTICES =====
This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
