[saag] Re: [Pqc] Re: Re: Re: [SAAG] A New Theo ry on Post-quantum Migration

John Mattsson writes:
> Composites that degrade the security properties should not be regarded
> as secure.

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?

The question should instead be what's best for real-world security. It's
important for other properties to be continually checked against that,
rather than becoming substitutes for it.

Here's an example. There's a problem right now of attackers recording
data to decrypt with future quantum computers. 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.

Skipping the ECC part would fail horribly on the second point.

But what if we write down protocols that really need the full strength
of IND-CCA2? Concatenation doesn't provide this. The question of whether
to declare concatenation unsafe is, at heart, a question of how
important those protocols are in the real world.

This is a happy case where we can address multiple problems at once.
Concretely, using Chempat instead of concatenation has negligible cost
and deals with the IND-CCA2 issue while still reducing the damage done
by PQ failures. But this still isn't achieving arbitrary "security
properties", nor is that an achievable goal.

> Empirically, adopting algorithms standardized by NIST has proven to be
> a very sound choice.

I would understand "very sound" to mean that the risk is negligible. But
DES was a security failure. DSA was a security failure. Dual EC was a
security failure. Many of the ECC security failures listed in

    https://cr.yp.to/papers/safecurves-20240809.pdf#chronology

came from adopting NIST standards.

If the claim is instead that the chance of a NIST standard failing is
lower than the chance of an alternative choice failing, then there needs
to be quantification of how many NIST standards there have been and how
many have failed, and similarly clear statements about the alternative
for comparison.

---D. J. Bernstein


===== NOTICES =====

This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification.)

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]