[openpgp] Re: WG: BSI view on KEM combiners

["D. J. Bernstein" <[e-mail]>]

Paul Wouters writes:
> A few months delay against an as-of-yet
> theoretical quantum attack to ensure we got things right would be worth it to
> avoid wasting years of time of wrongly deployed data ending up being
> vulnerable.

This sounds very wrong to me from a security perspective. Sure, years of
risk would outweigh months of risk if the risks had the same probability
and impact; but let's look at what the actual risks are in this case.

There's tons of data being sent today that needs long-term
confidentiality: clients talking to lawyers, patients talking to
doctors, whistleblowers talking to journalists, etc. Attackers are
recording everything they can in the hopes of decrypting it later:

   https://www.forbes.com/sites/andygreenberg/2013/06/20/leaked-nsa-doc-says-it-can-collect-and-keep-your-encrypted-data-as-long-as-it-takes-to-crack-it/

If the encryption mechanisms we're using are breakable _later_ then
we're already failing _today_ to provide security: i.e., the starting
point is that we've already gotten encryption wrong and are giving user
data away to attackers.

Of course, we won't be absolutely sure that a quantum computer is
breaking RSA-2048 etc. until we've seen public demos; but waiting until
we're sure is not sensible risk management. The upgrades from ECC to
PQ+ECC (OpenSSH in April 2022, Google's ALTS announcement in November
2022, etc.) are at least _trying_ to solve the security problem here,
whereas delaying means exacerbating the security problem.

On the flip side, how do you imagine these upgrades from ECC to PQ+ECC
making security _worse_? Sure, there could be a program-partitioning
disaster such as a buffer overflow in the PQ software---which is why we
use tools such as valgrind and check path coverage. Or someone could
massively screw up the final hashing, which is why we check the hashing
carefully. The risks here are understood and controlled, while there's
nothing we can do to stop attackers from building a quantum computer.

To be clear, upgrading from ECC to PQ+ECC won't necessarily make
security better. We've seen many breaks of PQ proposals; for how often
this happens, see https://cr.yp.to/papers.html#qrcsp. But holding off on
deployment for this reason makes no sense---it's tantamount to choosing
a _definitely_ broken PQ proposal.

> > Are you suggesting that we now adopt draft-connolly-cfrg-xwing-kem, an
> > individual draft?
> That draft will be adopted in CFRG.

Evidence?

---D. J. Bernstein