Re: [openpgp] v5 Secret-Key Packet Formats

Werner Koch <wk@gnupg.org> Mon, 22 January 2018 09:25 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 35C93124B17 for <openpgp@ietfa.amsl.com>; Mon, 22 Jan 2018 01:25:32 -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 jl2mA8ExsYrv for <openpgp@ietfa.amsl.com>; Mon, 22 Jan 2018 01:25:29 -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 C2EFC1243F6 for <openpgp@ietf.org>; Mon, 22 Jan 2018 01:25:29 -0800 (PST)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1edYM4-0007yN-QS for <openpgp@ietf.org>; Mon, 22 Jan 2018 10:25:28 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1edYEG-0005MK-7M; Mon, 22 Jan 2018 10:17:24 +0100
From: Werner Koch <wk@gnupg.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: openpgp@ietf.org, Tom Ritter <tom@ritter.vg>
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> <87r2qn8pwk.fsf@wheatstone.g10code.de> <20180119230821.GD222163@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>, openpgp@ietf.org, Tom Ritter <tom@ritter.vg>
Date: Mon, 22 Jan 2018 10:17:16 +0100
In-Reply-To: <20180119230821.GD222163@genre.crustytoothpaste.net> (brian m. carlson's message of "Fri, 19 Jan 2018 23:08:21 +0000")
Message-ID: <87efmi2qxv.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=oil_passwd_Afghanistan_USDOJ_terrorism_FSF_Juiliett_Class_Submarine="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/VM4D-BIKQZcjyfVNo993Ol2aSe0>
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: Mon, 22 Jan 2018 09:25:32 -0000

On Sat, 20 Jan 2018 00:08, sandals@crustytoothpaste.net said:

> generally been a successful model that's been resistant to attacks
> involving the MAC.  The TLS model is "authenticate the entire packet".

Well, we do basically the same except that we need to leave out the
packet lengths because OpenPGP different here form TLS.  Find below my
changes on using non-chunked AEAD for secret keys and the SKESK.

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

Well, it won't be junk data if the implementaion supports all required
algorithms.  For example the SKESK uses AES-256 to encrypt the session
key and the AEAD Encrypted Data Packet uses AES-128.  I can't see a
security problem here.


Salam-Shalom,

   Werner



--8<---------------cut here---------------start------------->8---
    Do not used chunked AEAD encryption for secret keys and SKESK.
    
    This also gives examples on how to encode the additional data.

	Modified   middle.mkd
diff --git a/middle.mkd b/middle.mkd
index a48a6fb..b7be5c6 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1801,11 +1801,17 @@ ## {5.3} Symmetric-Key Encrypted Session Key Packets (Tag 3)
   * The encrypted session key itself, which is decrypted with the
     string-to-key object using the given cipher and AEAD mode.
 
-  * A final, summary authentication tag for the AEAD mode.
+  * An authentication tag for the AEAD mode.
+
+The encrypted session key is encrypted using one of the AEAD
+algorithms specified for the AEAD Encrypted Packet.  Note that no
+chunks are used and that there is only one authentication tag.  The
+Packet Tag in new format encoding (bits 7 and 6 set, bits 5-0 carry
+the packet tag), the packet version number, the cipher algorithm
+octet, and the AEAD algorithm octet are given as additional data.  For
+example, the additional data used with EAX and AES-128 consists of the
+octets 0xC3, 0x05, 0x07, and 0x01.
 
-The encrypted session key is encrypted 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.
 
 ## {5.4} One-Pass Signature Packets (Tag 4)
 
@@ -1990,9 +1996,12 @@ ### {5.5.3} Secret-Key Packet Formats
     string-to-key specifier.  The length of the string-to-key
     specifier is implied by its type, as described above.
 
-  * [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.
+  * [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.  If string-to-key usage octet was 253 the IV
+    is used as the nonce for the AEAD algorithm.  If the AEAD
+    algorithm requires a shorter nonce, the high-order bits of the IV
+    are used and the remaining bits MUST be zero.
 
   * Only for a version 5 packet, a four-octet scalar octet count for
     the following key material.
@@ -2037,9 +2046,15 @@ ### {5.5.3} Secret-Key Packet Formats
 are encrypted, including the MPI bitcount prefix.
 
 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.
+encrypted as one combined plaintext using one of the AEAD algorithms
+specified for the AEAD Encrypted Packet.  Note that no chunks are used
+and that there is only one authentication tag.  The Packet Tag in new
+format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), the
+packet version number, the cipher algorithm octet, and the AEAD
+algorithm octet are given as additional data.  For example, the
+additional data used with EAX and AES-128 in a Secret-Key Packet of
+version 4 consists of the octets 0xC5, 0x04, 0x07, and 0x01; in a
+Secret-Subkey Packet the first octet would be 0xC7.
 
 The two-octet checksum that follows the algorithm-specific portion is
 the algebraic sum, mod 65536, of the plaintext of all the algorithm-
@@ -2050,7 +2065,9 @@ ### {5.5.3} Secret-Key Packet Formats
 deprecated; an implementation SHOULD NOT use it, but should rather use
 the SHA-1 hash denoted with a usage octet of 254.  The reason for this
 is that there are some attacks that involve undetectably modifying the
-secret key.
+secret key.  If the string-to-key usage octet is 253 no checksum or
+SHA-1 hash is used but the authentication tag of the AEAD algorithm
+follows.
 
 
 ## Algorithm-specific Parts of Keys
@@ -2640,7 +2657,10 @@ ## AEAD Encrypted Data Packet (Tag 20)
 format encoding (bits 7 and 6 set, bits 5-0 carry 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.
+data.  The index of the first chunk is zero.  For example, the
+additional data of the first chunk using EAX and AES-128 with a chunk
+size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x10,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00.
 
 After the final chunk, the AEAD algorithm is used to produce a final
 authentication tag encrypting the empty string.  This AEAD instance is
--8<---------------cut here---------------end--------------->8---



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