Hi Robert, You may want to look into https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-14.html#section-3.1 .
Cheers, -Tiru On Wed, 27 Aug 2025 at 21:26, Sophie Schmieg <sschmieg= 40google....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
