[TLS] Re: Concerns about the current draft.

[tirumal reddy <[e-mail]>]

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