Re: [openpgp] v5 Secret-Key Packet Formats

Werner Koch <wk@gnupg.org> Thu, 18 January 2018 09:50 UTC

Return-Path: <wk@gnupg.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 5E19312EB0F for <openpgp@ietfa.amsl.com>; Thu, 18 Jan 2018 01:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 HMOWe-SHyLUA for <openpgp@ietfa.amsl.com>; Thu, 18 Jan 2018 01:50:30 -0800 (PST)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 815E012EB2A for <openpgp@ietf.org>; Thu, 18 Jan 2018 01:50:24 -0800 (PST)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1ec6py-00049a-I1 for <openpgp@ietf.org>; Thu, 18 Jan 2018 10:50:22 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ec6hl-0000cn-Di; Thu, 18 Jan 2018 10:41:53 +0100
From: Werner Koch <wk@gnupg.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Tom Ritter <tom@ritter.vg>, IETF OpenPGP <openpgp@ietf.org>
References: <87a7xjfk07.fsf@wheatstone.g10code.de> <CA+cU71ng8ssamWGgLg-LHkqo6Jk4YF=xTmzH-71AvkKm=njgBA@mail.gmail.com> <87y3l3dp2i.fsf@wheatstone.g10code.de> <20180113003757.GD5946@genre.crustytoothpaste.net>
Organisation: The GnuPG Project
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: "brian m. carlson" <sandals@crustytoothpaste.net>, Tom Ritter <tom@ritter.vg>, IETF OpenPGP <openpgp@ietf.org>
Date: Thu, 18 Jan 2018 10:41:47 +0100
In-Reply-To: <20180113003757.GD5946@genre.crustytoothpaste.net> (brian m. carlson's message of "Sat, 13 Jan 2018 00:37:57 +0000")
Message-ID: <87r2qn8pwk.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=Cohiba_target_UFO_crypto_anarchy_Qaddafi_Yukon_number_key_militia_M-"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/pjr269jJOMJv2W9qNs7lXiMqCo8>
Subject: Re: [openpgp] v5 Secret-Key Packet Formats
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 18 Jan 2018 09:50:36 -0000

Hello!

On Sat, 13 Jan 2018 01:37, sandals@crustytoothpaste.net said:

> 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 fully agree.

> * 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.

I understand this.  I am right now implementing this and figured a
couple of minor problems.  See below.

> * The chunk size was large enough to cover most current keys, and it
>   could be arbitrarily extended (using multiple chunks) to any future
>   keys.

Okay.  But that makes simple processing of secret key material more
complicated than needed.  I can imagine application which do not
implement encryption but want to handle protected secret keys.  A
non-chunked AEAD encryption makes this much easier.

> * 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 not a problem for bulk encryption , but blows up secret ECC keys
protecion.  But that is really minor.

> 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.

I have not seen other comments but let me prepare a patch to use
non-chunked AEAD for non-bulk data.

What I noticed in the AEAD mode:

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---

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)


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.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.