Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird,

[Justus Winter <[e-mail]>]

Alessandro Barenghi <[e-mail]> writes:

> An interesting bird's eye view on the sizes of ciphertexts/keypairs
> and speed of the current third round candidates is available here[**]
> (from slide 100 onwards).
>
> [**] https://csrc.nist.gov/CSRC/media/Projects/post-quantum-cryptography/documents/round-3/seminars/oct-2020-gaj-kris-presentation.pdf

That is a great pointer.  I think from the perspective of the protocol,
the biggest challenge is that OpenPGP can only express cryptographic
artifacts up to 2^16 bits, or 2^13 bytes.

Even if we assume that artifacts like keys, ciphertexts, signatures are
just comprised of a single component, that only impacts very few KEMs
(HCQ, FrodoKEM, and of course McEliece), of which only McEliece is a 3rd
round finalist.  But, given that all other finalists are based on
structured lattices, and NIST expects to select only one of those,
McEliece may very well be one of the selected algorithms.

It's a different picture for the signature schemes, though, where only
Falcon and Dilithium fit into OpenPGP's MPI envelope, both of which are
3rd round finalists.  The signature schemes seem to all trade off key
size vs. signature size, with only two schemes barely able to fit into
MPIs.  That is a bit disconcerting.  NIST seems to think so too, as they
are interested in more candidates.

I think we should revisit the way we store cryptographic artifacts in
OpenPGP.  Unfortunately, neither SOS nor SBS address the issue of
potentially large PQ artifacts.

Justus