IETF Logo Mail Archive

[openpgp] Pull request for AEAD encrypted data packet with GCM

"brian m. carlson" <sandals@crustytoothpaste.net> Mon, 13 February 2017 01:07 UTC

Return-Path: <sandals@crustytoothpaste.net>
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 7BC8A128824 for <openpgp@ietfa.amsl.com>; Sun, 12 Feb 2017 17:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net
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 gCUxNjfvjUrA for <openpgp@ietfa.amsl.com>; Sun, 12 Feb 2017 17:07:04 -0800 (PST)
Received: from castro.crustytoothpaste.net (castro.crustytoothpaste.net [75.10.60.170]) (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 182151294F0 for <openpgp@ietf.org>; Sun, 12 Feb 2017 17:07:04 -0800 (PST)
Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:254c:7dd1:74c7:cde0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id 6A483280AD for <openpgp@ietf.org>; Mon, 13 Feb 2017 01:07:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1486948022; bh=DMD7CZpB5P3aQ7UW6Q1F9YXKUhtpbG0kxg1Db8JKlT4=; h=Date:From:To:Subject:From; b=e0QxOb2Efs9olv5XjxxbNjwdGIKYlvFBh1gpPccna8X7TWOqo03+MY+MuFqyuEG5B oVKIdTJZptpj8PclQ6FVAaUpefzXaeziZsvwsKz4mWZ5GnFqEpoKwqae7XakNgyX1n gVpHaGbfxP3O+9pX81NqkJZK6aBvqsa6DRineIJTboyHorPmm9s4YXrviYSvLpGf5C OIi+8WRHEdo9QVWUSzjZP27WIkhVvT+z8mdd/b9crV87k2n9nMifl6XpS698wcQ5VV HdBM0igrXzUwT0cdOgnvoRYgmsf6udWmwin4ohUdyN5kWPAz0ZTm45NC0Q4fnVHPrt ANnlNAbhfVIfhcoUabH36SwV/EMMxcgWUPEts35XxY/LtsLD2/wxCyehUa0Xgt+ZC+ CJqo+JXEpznwNqz97vHXsKm9qLh719NxNWV3pnZMHGphbn6RMW2fQ8x3yqMlaMCF9Q TeuZqty52D+/xVuI0MC24unPjmsilOCswgYZEkaiZ1DfXyMtYlT
Date: Mon, 13 Feb 2017 01:06:58 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="mk4uo3b4hwzjsqck"
Content-Disposition: inline
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.9.0-1-amd64)
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/VMU9DimE10coNaAxnqs101VT5eA>
Subject: [openpgp] Pull request for AEAD encrypted data packet with GCM
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: Mon, 13 Feb 2017 01:07:05 -0000

I've opened a pull request that defines an AEAD encrypted data packet
using GCM.  This work is necessarily incomplete, because it doesn't
define a new version of the symmetrically-encrypted data packet, which
we'd want, and it doesn't define a new encoding for the secret key
packet.

GCM seems to be the uncontroversial choice here.  It's used in TLS and
other protocols, and it provides adequate security.  It isn't encumbered
by patents.  It performs reasonably well.

Other alternatives include OCB and CTR with HMAC.  I personally object
to OCB because it's patented, and while I like CTR with HMAC, it was my
impression that the rest of the working group would not share my
opinion.

While I understand that we are not interested in adding general
extensibility to the protocol, I opted to include an octet for the AEAD
algorithm in case someone wants to define OCB or something like
ChaCha20-Poly1305.  ChaCha20 cannot use GCM, but it is a popular
algorithm that performs well on many architectures and is well-suited to
embedded systems.

I've proposed this as a starting point and welcome further comments.

[0] https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/2
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

v2.23.0 | Report a Bug | By Email