[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 [127.0.0.1]) 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-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 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
References:
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
Hi, 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 mode. 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. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
- [openpgp] Pull request for AEAD encrypted data pa… brian m. carlson
- Re: [openpgp] Pull request for AEAD encrypted dat… Jon Callas
- Re: [openpgp] Pull request for AEAD encrypted dat… Stephen Farrell
- Re: [openpgp] Pull request for AEAD encrypted dat… brian m. carlson
- [openpgp] [PATCH] Add AEAD Encrypted Data Packet … brian m. carlson
- Re: [openpgp] Pull request for AEAD encrypted dat… Jon Callas
- Re: [openpgp] Pull request for AEAD encrypted dat… Jon Callas
- Re: [openpgp] Pull request for AEAD encrypted dat… brian m. carlson
- Re: [openpgp] Pull request for AEAD encrypted dat… Werner Koch
- [openpgp] Questions around AEAD packets Werner Koch
- Re: [openpgp] Questions around AEAD packets Tom Ritter
- Re: [openpgp] Questions around AEAD packets Werner Koch
- Re: [openpgp] Pull request for AEAD encrypted dat… Peter Gutmann
- Re: [openpgp] Questions around AEAD packets Derek Atkins