Re: [openpgp] v5 Secret-Key Packet Formats

"brian m. carlson" <> Sat, 13 January 2018 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF7CE1241FC for <>; Fri, 12 Jan 2018 16:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (3072-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c2Mrgn_FEJGN for <>; Fri, 12 Jan 2018 16:38:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C74E1200C5 for <>; Fri, 12 Jan 2018 16:38:35 -0800 (PST)
Received: from (unknown [IPv6:2001:470:b978:101:e6b3:18ff:fe98:41a3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D21D56045C; Sat, 13 Jan 2018 00:38:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1515803883; bh=kImGJSsLfrH3+M1HbNk2BILxr7wokyPD1ExF0xqo5dA=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=JfJ3kD3jSqF2z4yV5Xt26fJcgALWbyn2Lr24AMTCVXmVaJnqQuOF0uoXYYoUvI7o+ GQlvowQx7F4ABdD/erQA3MAcrWaeyvCSqzFm77M7b1P7lXeN5OHk3G8jifvoeb7XVe iojvnlmYzerQEubJWq2ccBLo8kAvD0IRUGRTrgcE2Q49ovo7E5amrofn83aMEyBNHX vYwh3WjKIUnHedtJWGNWnhxVthI+Xf2QHCC4y0Ao7vpnD2QnVJ7P/5BxAJPtUkIBn8 zbiH4kUPkSLo/K0DC69nZvtCXT3eMkYHAo4EyAa9DxtO/cNqQetdlfNprl+J4NJbuQ z+RqlTyKacawFO1QZ7PSIjNX35/Lx8qTZkYYw6n6nGM2nuQb1Qmlq+qOI/aa2vygDw xPtsBx2GBzv5crOC0Z4hUSlZ1xl1C6tRonJBnr1kTNj+W5wP9lKk9Jwdwax3WdB6tx DcF78GvvgV1qR0aKSWVg6gXVMzErhKIMAQF3cTt8t6iA1O/3OD9
Date: Sat, 13 Jan 2018 00:37:57 +0000
From: "brian m. carlson" <>
To: Tom Ritter <>, IETF OpenPGP <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV"
Content-Disposition: inline
In-Reply-To: <>
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.9.0-5-amd64)
User-Agent: Mutt/1.9.2 (2017-12-15)
X-Scanned-By: MIMEDefang 2.79 on
Archived-At: <>
Subject: Re: [openpgp] v5 Secret-Key Packet Formats
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Jan 2018 00:38:39 -0000

On Fri, Jan 12, 2018 at 05:22:45PM +0100, Werner Koch wrote:
> On Fri, 12 Jan 2018 16:22, said:
> > Would this be adding a new mode that would have to be implemented?
> > That is in addition to adding chunked AEAD we're now also adding
> > non-chunked AEAD?
> No.  Like the current CFB mode, AEAD will be used at 3 places:
>  1. Bulk data encryption
>  2. Encryption used by the secret-key session key packet (which makes it
>     possible to encrypt to several passphrases)
>  3. Encryption of the secret key.
> My claim is that the chunked mode is only used for 1.  For 2 and 3 we
> can avoid any chunked mode and thus do not need to assume a certain
> chunk size.
> Sure, we could also keep on using CFB for 2 and 3 but that would require
> a minimalist implementation to implement CFB and AEAD(EAX).

I don't have a strong preference between non-chunked or chunked,
although I do quite want to avoid relying on CFB for the future.

I wrote it the way I did for a couple of reasons:

* We have various uses of CFB throughout the document, some using an
  all-zero IV and random prefix and some using a real IV.  I wanted to
  provide one consistent technique for encrypting to reduce complexity.
* The chunk size was large enough to cover most current keys, and it
  could be arbitrarily extended (using multiple chunks) to any future
* The chunk size was small enough to be practical for low-resource
  devices without having to release ciphertext before tag verification,
  even if we have large keys.  (I know the non-chunked nature of the MDC
  packet has had DoS implications in GnuPG in the past.)
* The extra block at the end is required to avoid truncation attacks in
  chunked mode, and the cost of 16 bytes in the secret key packets
  didn't seem like a huge cost given the other constraints.

This is just a rationale, and if implementers or other folks think a
non-chunked approach for key material is better, I'm happy to go along.
brian m. carlson / brian with sandals: Houston, Texas, US | My opinion only