[TLS] Re: [EXT] Re: Concerns about the current draft.

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

1. We do not have to have the same strength level in all the primitives that or combination uses. True, combining RSA-2048 with AES-256 does not increase the total strength of the construction above 128 bits - but since (in many cases ) the cost of AES-256 is roughly the same as that of AES-128, often it’s simpler to just stick with AES-256 everywhere, and reduce the code-base. With RSA - you’ll need to replace it with an entirely different algorithm, being able to reuse only the logic of the protocol. 

2. How hard, in your opinion, would switching an app that currently uses only AES-128 to AES-256 would be? 

3. Those customers you’re referring to, seem to have a non-scientific approach, IMHO. Of course, you still need to do what they want - understandably. 

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Aug 25, 2025, at 06:45, Bas Westerbaan <bas=[e-mail]> wrote:



Thanks Eric. Let me add a few more words. Although opinions differ on whether Grover's algorithm will ever be practical, there is no debate that attacks with Grover's algorithm are much further out in the future than Shor. There are

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

Thanks Eric. Let me add a few more words.

Although opinions differ on whether Grover's algorithm will ever be practical, there is no debate that attacks with Grover's algorithm are much further out in the future than Shor. There are some advantages moving to 256 bit symmetric ciphers apart from countering Grover, and it's not that expensive, so quite a few experts will not bother debunking the misleading "we must double symmetric key size because of quantum". I have two objections with that though.

To start, I do not think we have enough time and resources to migrate everything. Not by a long shot. I would rather have someone spend their limited efforts on upgrading RSA somewhere, instead of AES-128.

Secondly, if we do insist on AES-256, then we must match our asymmetric cryptography to that as well. In stark contrast to symmetric cryptography, moving to 256 bits for asymmetric cryptography is much more expensive.

Now, you might also notice that ML-KEM-768 is designed to match AES-192, whereas X25519 roughly matches AES-128. That's intentional: we picked ML-KEM-768 not to match AES-192, but to have a big margin on top of AES-128 in case there is cryptanalytic advance.

Finally I would like to note another reason for traditional/PQC hybrids. Most people simply don't care about post quantum cryptography, but they do care about their existing security or compliance. Many of our customers would be quite uncomfortable with us switching completely to some newfangled cryptography. It can be done, but it takes more time, and I don't think we have that much time left. Hybrids sidestep the problem, as it will allow us to deploy PQC by default.

Best,

 Bas

On Sun, Aug 24, 2025 at 10:35 PM ma bing <[e-mail]> wrote:

Some websites including Google is using the experimental ECC+Kyber hybrid solution, but Google and others  still use AES-128, quantum computer can weaken 128-bit symmetric encryption to 64-bit security, it's the 1st concern. So the draft should only use AES-256. And NSA suggests 1024-dimensional MLKEM, the 2nd concern is that Google and others use MLKEM768. The 3rd concern is that the draft uses ECC in addition to Kyber. NIST has approved HQC (Hamming Quasi-Cyclic) in addition to the already approved ciphers, I suggest to switch from ECC+Kyber to HQC+Kyber; Since ECC is vulnerable to quantum computer, using ECC+Kyber is likely a false positive, so I think HQC+Kyber is better. In conclusion, I think there are 3 concerns.

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]