logoalt Hacker News

mswphdyesterday at 7:21 PM1 replyview on HN

DJB wrote this article after asking people to brigadge the current TLS-WG's attempt to get rough consensus on a current draft RFC for pure ML-KEM. This is clearly part of this tirade for that.

ML-KEM is not new. It's hardness is based on MLWE. LWE (a slightly harder problem) has been around for 20 years. Attacks against it stablized to be 2^{cn} time maybe 15 years ago. The value of c has been stable for nearly 10 years.

MLWE is mildly different, but still from > 1 decade ago. The only improved attacks are ~8x faster (and they are relatively naive). It has been a very popular cryptanalytic target since it was suggested (LWE has been dominating cryptography for the last >10 years).

It does not add negligible cost in all settings. In hardware, a hybrid scheme requires an implementation of SHA2 and SHA3. This is expensive.

Any good design must not do fine when even the worst happens. When we did the AES competition, we did not combine AES with DES (or 3DES) in case AES was weak.

This is beside the point though. Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason. In these settings, they should implement it against some standard, so it is interoperable.


Replies

tveitayesterday at 9:37 PM

> Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason.

That's exactly how it was with Dual_EC_DRBG.

E.g. https://www.schneier.com/essays/archives/2007/11/did_nsa_put...

   I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
  
  My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances.
So most cryptographers _recommended_ staying the hell away from Dual_EC_DRBG. But hey, harmless, no one serious about security would actually use it right?

Except as we know now, after the standardization NSA was able to persuade/bribe vendors to implement it.

RSA is still a viable cryptography vendor, after accepting money to backdoor their product for paying customers. The standardization gave them a fig leaf of plausible deniability. Honest mistake, could happen to anyone, right? If they had needed to implement a "non-standard" backdoor, or if it had been officially struck from the standard, it would have been a lot harder to row away from.

show 1 reply