> > You’re right, I should have said “less secure” about NewHope. > > The additional algebraic structure leads to more angles of attack > > which for other rings (e.g., non-cyclotomic ones) has led to problems. > > I believe this is why NIST preferred Kyber over NewHope. >
Less attack surface, more flexibility and still great performance. The choice makes a lot of sense. > And there HAVE been partially successful “special” and “implementation” > attacks > > (e.g., *Security of NewHope Under Partial Key Exposure*). > > And now that ring-based LWE has not been selected less effort is being > expended in that direction. > As you hint at, attacks often develop from special / simpler cases. It still makes sense to look at ring-LWE if you want to attack module-LWE. And even though ring-LWE is not deployed today, it surely still is a career-defining achievement. > ML-KEM is delightfully simple? > > Granted that it has only 3 primitives, and reuses NTT and Keccak, > > but like any new protocol it has numerous pitfalls and edge conditions > > and I have been told that it isn’t easy to implement efficiently while > protecting against timing attacks. > Implementing any cryptography unfortunately comes with sharp edges. Compared to ECC, ML-KEM is indeed simple in my experience. > What would convince me? > > 1. 5 years from now with no significant compromise discovered > > > > OR > > > > 2. CRQCs become so prevalent that it is inexpensive to Shor ECDLP > algorithms > > > > OR a combination of > > > > 3. tighter (dimension preserving) reductions of ML-KEM to general SVP > for real parameter choices > > AND > > 4. analytical evidence that you can’t beat LLL/BKZ approaches to > structureless SVP > > > > OK, I am sure that you will say that this latter is a stricter condition > than that applied to RSA/ECDLP > No, I think your list is defensible. I don't see a need to move to pure ML-KEM anytime soon as we have X25519MLKEM768 already. And if we move away from X25519MLKEM768, it'll probably be a better PQ KEM. I do see a need to move to ML-DSA, for which there is no agreement on *which* hybrid to use. There it's the spectre of your point (2) together with migration timelines that weighs heavily for me. Best, Bas > - > > but > > 1. this is according to Sagan’s standard > > *the more a claim departs from the status quo, the stronger the evidence > required to accept it* > > 2. there is strong experimental evidence that these are really > subexponential > 3. there was no previous generation with which to hybridize these > > in case of someone finding a polynomial algorithm. > > > > Y(J)S > > > > > > *From:* Bas Westerbaan <[email protected]> > *Sent:* Monday, June 29, 2026 6:02 PM > *To:* Yaakov Stein <[email protected]> > *Cc:* Antony Vennard <[email protected]>; Joseph Salowey <[email protected]>; > [email protected]; [email protected]; [email protected] > *Subject:* Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends > 2026-07-08) > > > > That is a good argument, but the crux is "no attack has been demosntrated" > is not the same as "no attack will be found" > and certainly not the same as "no attack exists". > Modular LWE (k>1) is a compromise between efficient but insecure Ring > based (k=1) LWE, and complex but more secure LWE over the integers. > > > > Sorry, I must've missed the memo, but could you give me a pointer why the > RLWE scheme A New Hope is "insecure"? > > > > I'd say MLWE is simpler to implement if you're doing more than one > security level. Also, taken as a whole, ML-KEM is a delightfully simple > algorithm. > > > > We can't yet be sure that this compromise is as secure as it seems. > > > > You wrote "yet". What would make you change your mind? > > > > Best, > > > > Bas > This message is intended only for the designated recipient(s). It may > contain confidential or proprietary information. If you are not the > designated recipient, you may not review, copy or distribute this message. > If you have mistakenly received this message, please notify the sender by a > reply e-mail and delete this message. Thank you. >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
