[Pqc] Re: [EXT] Re: [saag] Re: Re: [SAAG] A New Theory on Post-quantum Migration

"Blumenthal, Uri - 0553 - MITLL" <[email protected]> Tue, 4 Nov 2025 19:54:45 +0000
Newsgroups gmane.ietf.pqc,gmane.ietf.saag
Message-ID <BN0P110MB1419BA852C5F5B91335D8C8190C4A@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
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]
smime.p7s (application/x-pkcs7-signature, 8.9 KB) - not displayed