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

Justus Winter <justus@sequoia-pgp.org> Mon, 28 June 2021 10:36 UTC

Return-Path: <justus@sequoia-pgp.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D53A3476 for <openpgp@ietfa.amsl.com>; Mon, 28 Jun 2021 03:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPuzHwprJlaY for <openpgp@ietfa.amsl.com>; Mon, 28 Jun 2021 03:36:22 -0700 (PDT)
Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7893A347D for <openpgp@ietf.org>; Mon, 28 Jun 2021 03:36:21 -0700 (PDT)
Received: (qmail 2448 invoked from network); 28 Jun 2021 10:36:19 -0000
Received: from localhost (HELO localhost) (127.0.0.1) by harrington.uberspace.de with SMTP; 28 Jun 2021 10:36:19 -0000
From: Justus Winter <justus@sequoia-pgp.org>
To: Alessandro Barenghi <alessandro.barenghi.polimi@gmail.com>
Cc: openpgp@ietf.org
In-Reply-To: <CA+DWVEPEmeCNQE+L5Vu_0CJBoLq7-vkpJoRxLwv47Ycj8P63=w@mail.gmail.com>
References: <c2b4b0ea-ed14-79a0-c547-5fe79fc35fc0@kuix.de> <CA+DWVEPEmeCNQE+L5Vu_0CJBoLq7-vkpJoRxLwv47Ycj8P63=w@mail.gmail.com>
Date: Mon, 28 Jun 2021 12:36:17 +0200
Message-ID: <8735t246ou.fsf@europ.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/cUTLEANtkI2x-3X8tAR2aJUl3K4>
Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird,
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2021 10:36:27 -0000

Alessandro Barenghi <alessandro.barenghi.polimi@gmail.com> 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