[openpgp] v5 Secret-Key Packet Formats

Werner Koch <wk@gnupg.org> Fri, 12 January 2018 10:35 UTC

Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8E5631267BB for <openpgp@ietfa.amsl.com>; Fri, 12 Jan 2018 02:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AJLghwC5-Dgs for <openpgp@ietfa.amsl.com>; Fri, 12 Jan 2018 02:35:15 -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 20109124E15 for <openpgp@ietf.org>; Fri, 12 Jan 2018 02:35:14 -0800 (PST)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1eZwg5-0002Ko-KZ for <openpgp@ietf.org>; Fri, 12 Jan 2018 11:35:13 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1eZwaM-0000pI-Il; Fri, 12 Jan 2018 11:29:18 +0100
From: Werner Koch <wk@gnupg.org>
To: openpgp@ietf.org
cc: brian m. carlson <sandals@crustytoothpaste.net>
Organisation: The GnuPG Project
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: openpgp@ietf.org, brian m. carlson <sandals@crustytoothpaste.net>
Date: Fri, 12 Jan 2018 11:29:12 +0100
Message-ID: <87a7xjfk07.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=terrorism_Abu_Ghraib_Israel_White_House_NATO_CNCIS_CDMA_ammunition=l"; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/47lgilGm4r2Y26ygf-QSwGyH84U>
Subject: [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: Fri, 12 Jan 2018 10:35:17 -0000


The protection of secret keys usning AEAD has this requirement:

   If the string-to-key usage octet is 253, the encrypted MPI values are
   encrypted as one combined plaintext exactly as an AEAD Encrypted Data
   packet with a chunk size octet of 10 would be.  This implicit chunk
   size octet is included in the normal calculations of additional data.

Given chunk_size = ((uint64_t)1 << (c + 6)) this works only for keys
requiring less than 64 KiByte for the secret parameters.  This may not
be enough in the future and thus I suggest to increase the default chunk
size.  A value of 20 would allow for 64 MiByte which should be enough,
but 25, resulting in 2^31 would be more logical.

However, there is a practical problem using chunks for secret key (and
also with Symmetric-Key Encrypted Session Key Packets): we need to run
two AEAD encryptions for those commonly short key packets because our
description of the AEAD says:

   After the final chunk, the AEAD algorithm is used to produce a final
   authentication tag encrypting the empty string.  This AEAD instance
   is given the additional data specified above, plus an eight-octet,
   big-endian value specifying the total number of plaintext octets
   encrypted.  This allows detection of a truncated ciphertext.

This is overhead in the implementation and the specification (question
of the default chunk size).  I would prefer that we remove the use of
the chunked AEAD encryption from Secret-Key and Symmetric-Key Encrypted
Session Key Packets.  Thus instead of

  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.

we make use of the parameters already in the Secret-Key Packet:

  * [Optional] If string-to-key usage octet was 255, 254, or 253, a one-
    octet symmetric encryption algorithm.

  * [Optional] If string-to-key usage octet was 253, a one-octet AEAD


  * [Optional] If secret data is encrypted (string-to-key usage
    octet not zero), an Initial Vector (IV) of the same length as
    the cipher's block size.

The IV already matches our requirement for EAX and for OCB we would set
its LSByte to zero.  The description of the AEAD mode needs to be
changed to explain the chunked and the non-chunked mode.

What do you think?



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.