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 <bingm...@outlook.com> 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 -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
