[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]