"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." Huh. I can actually provide the objective, definitive answer to your speculation. I preferred Kyber over NewHope for a straightforward reason: NewHope had only Cat 1 and Cat 5 parameter sets, but not a Cat 3 parameter set. Kyber had Cats 1, 3, and 5. I don't know what to say about the rest of your email; I don't have anything good to say there. On Tue, Jun 30, 2026 at 8:40 AM Yaakov Stein <ystein= [email protected]> wrote: > Bas, > > > > 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. > > 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. > > > > 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. > > I once implemented AES (which is trivial compared to Kyber) in FPGA > > and came away with a healthy respect for getting simple things right in > low level production code. > > > > 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 - > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
