Note in particular that the same "covert" channel is available in X25519 and its hybrids, assuming the adversary has access to a quantum computer, as the ephemeral private key is not hashed. The whole discussion is nonsensical, has nothing todo with the draft in question, and shows lack of familiarity with cryptographic protocols and primitives. If your ship was hit by a cannon ball, you fix the hole (i.e. deprecate DUAL_EC_DRBG), but you then do not go ahead and expend all your repair supplies on further hardening this particular part of the hull, given that the next cannon ball is sure to come, and equally sure to hit somewhere else entirely. Unnecessary hash function calls do have a cost, and if they do not provide meaningful defense in depth (such as the hash of shame), they should be omitted, and the effort/latency budget be invested in more impactful hardening exercises.
On Mon, Jul 13, 2026 at 8:03 AM Paul Wouters <paul= [email protected]> wrote: > On Mon, 13 Jul 2026, Jacob Appelbaum wrote: > > > It is not a red herring against pure ML-KEM. ML-KEM is not broken. > > I'm glad to hear you think this, > > > I agree that both ML-KEM drafts should get equal treatment. > > I'm glad to hear you say this. > > > The equal treatment should be to restore the Kyber hash in both drafts. > > I don't think that is an option in MLKEM drafts. It could be an option > in a Kyber draft if you submit that. > > The sentence added would be about using good strong random, not about > adding a hash. If as part of good strong random, an implementer feels > the need to run a hash over RDRAND() or whatever OS source you are using, > implementers can decide to do so on their own. It would be generic > advise and apply to all parts that need randomness. > > Paul > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
