[TLS] Re: Concerns about the current draft.

[Sophie Schmieg <[e-mail]>]

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=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]