[Pqc] Re: [EXT] Re: [saag] Re: Re: [SAAG] A New Theory on Post-quantum Migration
Deirdre Connolly <[email protected]> Wed, 5 Nov 2025 11:21:19 -0500
| Newsgroups | gmane.ietf.pqc,gmane.ietf.saag |
|---|---|
| Message-ID | <CAFR824z0eAF6uS6h27fJfP_68bLis-j05UvQdzjdtqcxOHMp4g@mail.gmail.com> |
> I’ll also add that Lattice-based crypto (Kyber, NTRU) has formal proofs, while ECC crypto does not. 😉 You mean the lower-bound proofs on (iirc) unstructured lattices? On Wed, Nov 5, 2025, 10:55 AM Blumenthal, Uri - 0553 - MITLL <[email protected]> wrote: > ZjQcmQRYFpfptBannerEnd > > My take, > > If ECC is anyhow prone to Quantum attack and also the part of > implementation is old and received by the attackers, then why are we > planning traditional crypt+ pqc (NIST approved). > > > > In my understanding, that planning is a mistake – a combination of > overestimating the risk of Lattice-based crypto failure (has been studied > for about 30 years, compared to about 50 years of ECC crypto studies), and > underestimating the likelihood/speed of CRQC arrival. > > > > Their hope basically is that the protected data will lose all value > *before* CRQC arrives, and *maybe* the QC part will hold. > > > > Instead we should focus on rapid migration techniques for the infra > collaborating with big players like DigiCert, checkpoint, hp, for the pure > pqc migration. > > Design and Evaluation of StrongVPN, a Pure Post-Quantum VPN Architecture > <https://www.techrxiv.org/users/978467/articles/1345362-design-and-evaluation-of-strongvpn-a-pure-post-quantum-vpn-architecture> > > > > IMHO, that is correct. > > > > > https://www.techrxiv.org/users/978467/articles/1345362-design-and-evaluation-of-strongvpn-a-pure-post-quantum-vpn-architecture > > I totally understand that the proven technology is more convincing to the > industry then the future evolution. > Even if we are considering the migration techniques, do we have any plan > under discussion so far. > > I’ll also add that Lattice-based crypto (Kyber, NTRU) has formal proofs, > while ECC crypto does not. 😉 > > > > > ------------------------------ > > *From:* Blumenthal, Uri - 0553 - MITLL <[email protected]> > *Sent:* 04 November 2025 19:54 > *To:* [email protected] <[email protected]>; [email protected] <[email protected]> > *Subject:* [Pqc] Re: [EXT] Re: [saag] Re: Re: [SAAG] A New Theory on > Post-quantum Migration > > > > My take. > > > > Does this mean ECC+PQ can be declared insecure on the basis of, e.g., > declaring that small code size is a "security property" and that ECC+PQ > is more code than just PQ? The only good cipher is the null cipher? > > > > Yes, it can. An extra attack surface is an extra attack surface. > > > Here's an example. There's a problem right now of attackers recording > data to decrypt with future quantum computers. > > > > In that case, ECC part is irrelevant – helping *at best* only until CRQC. > > > > There are protocols such > as TLS responding to this by rolling out ECC+PQ concatenation: > > * Maybe the PQ part holds up. If so, big step forward! > * Maybe the PQ part ends up as another disaster. If so, at least > ECC+PQ isn't worse than current normal usage of ECC. > > > > If the data sensitivity persists through the appearance of CRQC – which is > the main purpose of the governments driving PQC rollout – then ECC+PQ is > exactly as secure as PQ alone, not counting for implementation bugs that > could make it worse. > > > Skipping the ECC part would fail horribly on the second point. > > > > Not at all. It might only help for “short-lived” data. If that’s all you > care for – then ECC+PQ (or ECC alone) would work fine for you. Otherwise – > it’s a waste of time and resources to even argue about it. > > > -- > Pqc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Pqc mailing list -- [email protected] To unsubscribe send an email to [email protected]