[openpgp] Questions around AEAD packets

Werner Koch <wk@gnupg.org> Tue, 14 February 2017 09:22 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 BF82F12956E for <openpgp@ietfa.amsl.com>; Tue, 14 Feb 2017 01:22:30 -0800 (PST)
X-Quarantine-ID: <7U4baybJooZK>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
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 7U4baybJooZK for <openpgp@ietfa.amsl.com>; Tue, 14 Feb 2017 01:22:29 -0800 (PST)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E009129546 for <openpgp@ietf.org>; Tue, 14 Feb 2017 01:22:29 -0800 (PST)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1cdZJb-0003Om-I9 for <openpgp@ietf.org>; Tue, 14 Feb 2017 10:22:27 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1cdZF1-0000F6-Ac; Tue, 14 Feb 2017 10:17:43 +0100
From: Werner Koch <wk@gnupg.org>
To: openpgp@ietf.org
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>, Jon Callas <joncallas@icloud.com>
Date: Tue, 14 Feb 2017 10:17:42 +0100
In-Reply-To: <CE43260E-D723-4B00-9E81-B5F81142121F@icloud.com> (Jon Callas's message of "Mon, 13 Feb 2017 17:09:49 -0800")
Message-ID: <87shnhxhah.fsf_-_@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=red_noise_Skipjack_John_Kerry_assassination_Mossad_high_security_ass"; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/B7O2qXsSf4MYAFhCClH9G58pJps>
Cc: Jon Callas <joncallas@icloud.com>, "brian m. carlson" <sandals@crustytoothpaste.net>
Subject: [openpgp] Questions around AEAD packets
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 14 Feb 2017 09:22:31 -0000


putting the patent mess aside, there are also a few other question
involved in a new encryption mode:

 1. Exactly one mode defined by a new packet number
    or a new packet with a parameter to define the mode?
 2. Bind the mode to a certain cipher algorithm?  For example only allow
    a mode with AES.

 3. How can we do early detection of corruption?  When decrypting
    several gigs we should be able to detect corrupted data after having
    processed, say, one gig.  Shall such a feature be configurable?
    Shall we link it to partial length headers.

My ideas here are:

 re 1. A new packet with a parameter to define the actual mode.  Make
       one mode mandatory.  Additional parameters should have a length
       header so that parsers have an easier way to parse the header
       even if they don't implement that mode.
       The rational for this is to allow for some experimentation and
       separate the packet format from the finally chosen mandatory

 re 2: Binding a mode to an algorithm makes testing easier.  This will
       also make implementing stream cipher modes easier because it
       allows to blur the distinction between cipher algorithm and mode.

 re 3: The simplest idea would be to use fixed chunks of the ciphertext
       and either link them together using a counter or the hash of the
       previous authentication tag.  The packet header would give the
       length of the chunks in blocks.  It needs to be decided whether a
       final one-block chunk is okay.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.