On Sun, Aug 24, 2025 at 1:35 PM ma bing <[email protected]> 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. > I assume "the draft" you are referring to is: https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-00.html? Assuming so, this draft doesn't use either AES-128 or AES-256. In TLS 1.3, negotiation of key establishment algorithms is orthogonal to negotiation of symmetric cipher suites. I know opinions differ on whether in fact it's important to use 256-bit symmetric algorithms to defend against CRQCs (see https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-13.html#name-symmetric-cryptography for a contrary position) but in any case it's irrelevant for this draft. > And NSA suggests 1024-dimensional MLKEM, the 2nd concern is that Google > and others use MLKEM768. > This draft specifies both MLKEM-768 and MLKEM-1024. NSA requires MLKEM-1024 for National Security Systems, but I don't think that should lead us to the concludion that MLKEM-768 should never be used. For example, RFC 9151 specifies the CNSA profile for TLS (for traditional algorithms) and requires P-384, but commercially P-256 and X25519 are far more common. > 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. > The rationale for this design is to have an algorithm that we have high confidence in in the setting where a CRQC is not available and combine it with an algorithm that we have less overall confidence in but that is designed to be quantum-resistant. That way if the newer PQ algorithm is broken in some other way than the development of a CRQC, we have had no loss of security. Substituting HQC for ECC would not achieve this objective. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
