As Bas mentioned, there is currently no indication that Grover's algorithm can practically break AES-128 any time soon. Grover's algorithm is inherently sequential, and cannot be parallelized, making the standard approach of throwing more compute at the problem to scale up infeasible. I see no reason to reassess [1] further at this point, any follow up research I have seen has confirmed the infeasibility of Grover's in at least the medium term of several decades to centuries.
Switching from AES-128 to AES-256, while not the biggest deal in software (~40% performance degradation due to the additional rounds, down to ~25% increase when measuring AES-GCM end-to-end, due to the authentication part not changing), once you have e.g. hardware dependencies, the story changes substantially, and migration can become very difficult. Combined with the fact that, to the best of my knowledge, it is also completely unnecessary, I'm not going to recommend that switch proactively, or when the costs are anything but marginal, as not wasting resources is part of my job and obligation as an engineer. There are several reasons for hybrids, and while I agree that the reason for ECC + lattice based hybrids are becoming less compelling with every day that passes in which lattices do not get broken, I see little point to an HQC+ML-KEM hybrid. My trust in lattice cryptography is very high, and the biggest risk to ML-KEM, novel discoveries in algebraic number theory, would likely have consequences for code based cryptography as well, making FrodoKEM arguably the better fallback (and hybridizing with FrodoKEM would be meaningless). Sophie [1] https://eprint.iacr.org/2017/811 On Tue, Aug 26, 2025 at 4:02 PM Robert Relyea <rrelyea= 40redhat....@dmarc.ietf.org> wrote: > On 7/30/25 2:17 AM, ma bing wrote: > > 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. > > Eric already addressed the main concern. Hybrid is to give us confidence > to deploy these new algorithms. > > The other issue is HQC is also significantly larger than ML-KEM*. Part > of what makes hybrid doable is that ECC is realtively small, so adding > it does not add significant size over ML-KEM's own keys. Performance was > such that Amazon found that they could 'just do it' and keep chugging. > That removes a significant barrier to deployment. > > The second issue is there is a lag time between 'approval' and > standards. NIST has decided to move forward with HQC as a NIST standard, > but that standard is not yet available. One it is I would expect to see > HQC-ECC hybrids out there as well, just so our infrastructure doesn't > fall over if ML-KEM becomes classically broken, but as I said, there is > no HQC standard, so > > Bob > > *I'm taking your use of Kyber to mean ML-KEM. Typically we refer to > Kyber when we are talking pre-standardized variants of the algorithm. > Using HQC would have the same issues as using Kyber (rather than > ML-KEM). It was a stop-gap until we had ML-KEM. > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
