Re: [openpgp] v5 Secret-Key Packet Formats

"brian m. carlson" <> Fri, 19 January 2018 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC28212D876 for <>; Fri, 19 Jan 2018 15:08:30 -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 hYKJRmoe29zz for <>; Fri, 19 Jan 2018 15:08:28 -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 6B82F126C19 for <>; Fri, 19 Jan 2018 15:08:28 -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 533486052F; Fri, 19 Jan 2018 23:08:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1516403306; bh=HPzghJVIdpwGy1JcpEa+frPZa3uwXzkuw+OyVtFS18w=; h=Date:From:To:Cc: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=TwpX9e8+6mn9pq6DcQLOsvzA6djdVnrxEjDlNLto40iKNlsjavod0WU6GZO3UGdC8 7jmBp5ljW8C0gvLNBNlFzA7u7dZh/ZfGyVNZ0eLgVp2GacOQ4vRCQODAT3RVU6N/7i PTx/QHAazL6nTpgajo2Y1OxAic3LB1o9SZ4TuzEpkQvkm/P3ouwQ3ioXbG/mHJ7krZ t2xzHWhwWfKazNTnKSMuPNpSr0uj4iKbzq8gQHb7WPskK7vk+lIiAZaFTChGL1ulQt DvdZOUsvkdK9ihCV51xEsq2g5P91xItm2z1XiSU7jACEinKjcSySVufTaxD2Scyelt plq3/2NebsaTi6Uyj1b+uG1v+lR9ZgspE7hJ8EnlR5INDCnGzraMWjrn7tEQlPy/m2 GdJ25Fp+RaWzthuCPRmeS5K+VRBM4Lf1Dsh3GnYBtSYAVl/bdZWIJZeysoidsgHfa0 jxCZTI441P5XBAJ5my84tuB6G76ydYpnHdaBpbOdJd0cJciSGpB
Date: Fri, 19 Jan 2018 23:08:21 +0000
From: "brian m. carlson" <>
Cc: Tom Ritter <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AkbCVLjbJ9qUtAXD"
Content-Disposition: inline
In-Reply-To: <>
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.14.0-3-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: Fri, 19 Jan 2018 23:08:31 -0000

On Thu, Jan 18, 2018 at 10:41:47AM +0100, Werner Koch wrote:
> 1. There is a problem including the entire packet header in the
>    additional data: When using partial length encoding we would need to
>    use the first partial length here.  gpg uses a a pipeline of
>    functions as data structure.  Thus the encryption layer does not know
>    how the next function down the line will block the data to emit the
>    partial length encoding.  Sure this can be hacked around but it would
>    be ugly.  Thus I propose this change:
> --8<---------------cut here---------------start------------->8---
> -For each chunk, the AEAD construction is given the packet header,
> -version number, cipher algorithm octet, AEAD algorithm octet, chunk size
> -octet, and an eight-octet, big-endian chunk index as additional
> -data.  The index of the first chunk is zero.
> +For each chunk, the AEAD construction is given the Packet Tag, version
> +number, cipher algorithm octet, AEAD algorithm octet, chunk size
> +octet, and an eight-octet, big-endian chunk index as additional data.
> +The index of the first chunk is zero.  Note that the Packet Tag has
> +the value 0xd4 and that the length octets are not included because
> +they may vary in case of a partial body length.
> --8<---------------cut here---------------end--------------->8---

That should be fine.  We detect truncation elsewhere anyway.

> 2. The above immediately raises the question why we need the Packet Tag
>    at all.  After all it will be a constant (the AEAD packet requires a
>    new style CTB and thus there is only one encoding).  I assume you did
>    this to prepare against a future rollback attack in case we ever
>    introduce a new style AEAD encryption.  But then, why do we have the
>    version number as first item in the AEAD packet?  It can serve the
>    same purpose.  Or is this to distinguish between AEAD used for bulk
>    encryption and secret key encryption?  What packet tag would we use
>    for the latter (with old-style CTB we can have several encodings)?
>    Shouldn't we either drop the packet header from the additional data
>    or can we define fixed values depending on the use like:
>      0xd4 := AEAD Encrypted Data Packet  (tag 20)
>      0xc3 := SKESK (Symmetric-Key Encrypted Session Key Packet, tag 3)
>      0xc5 := Secret-Key Packet (tag 5) and Secret-Subkey Packet (tag 7)

It's a good idea to use domain separation to ensure that packets can't
be copied and pasted between packet types.  It prevents cases where
someone accidentally creates a decryption oracle and reuses keys or
passphrases.  The packet tag should be enough for this, since the
authentication tag will flag the failure immediately if it changes.

I tried to model the AEAD authenticated data after TLS, since that has
generally been a successful model that's been resistant to attacks
involving the MAC.  The TLS model is "authenticate the entire packet".

> 3. The AEAD Encrypted Data Packet specifies the cipher algorithm to use.
>    The old encryption modes had no way to specify the algorithm.
>    Instead they take the algorithm either from the SKESK or the PKESK
>    (Public-Key Encryption Session Key Packet, tag 1).  For simple
>    encryption without even an SKESK it is implementation defined how to
>    get the algorithm.
>    I like that algorithm id in the AEAD packet.  But should we specify
>    what to do on a conflict and whether it is allowed that the SKESK
>    uses a different algorithm than that in the AEAD packet?  I currently
>    print a warning and continue but I am not sure whether this is really
>    needed.  The potential for a conflict has always been in OpenPGP: A
>    faulty implementation may encrypt to several keys giving different
>    algorithms in each PKESK and thus not all recipients would be able to
>    decrypt the message.  I am not ware of such bug, though.

I would just say a hard error is the right thing to do.  Clearly if
there's disagreement, we can't be sure what the sender intended.  It
would be better to fail than produce a bunch of junk data.
brian m. carlson / brian with sandals: Houston, Texas, US | My opinion only