From nobody Mon Feb 6 09:10:30 2017 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03770124281; Mon, 6 Feb 2017 09:10:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148640102898.18999.14928493172416550288.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 09:10:28 -0800 Archived-At: Cc: openpgp-chairs@ietf.org, openpgp@ietf.org, barryleiba@gmail.com, stephen.farrell@cs.tcd.ie Subject: [openpgp] openpgp - Not having a session at IETF 98 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:10:29 -0000 Barry Leiba, a chair of the openpgp working group, indicated that the openpgp working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Feb 6 09:17:54 2017 Return-Path: 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 6BCA0129408; Mon, 6 Feb 2017 09:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YYtBM69sVpdM; Mon, 6 Feb 2017 09:17:42 -0800 (PST) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 F418B1295A3; Mon, 6 Feb 2017 09:17:41 -0800 (PST) Received: by mail-io0-x243.google.com with SMTP id 101so10054732iom.0; Mon, 06 Feb 2017 09:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5UwbHV1wY9wTRH98jCnH3gmlSk1rVa3C7U6ZZbfROeg=; b=kLc1Y3mCqhY2PFzpXrBxgvkuEXuJ9a2K5QymM8Qz0uyEDF3fV/nEbUVJp3g3LVGZgi YtPjt4r8cXUcNFCW/qgp0oWeAIuSzlqHoJVrOGWNBv8EriQ9VnQF/V2qB2CgdfaW5qoJ vRM5x60erw9O6rkwe+taHYj10MktOVsW1zJIR2VQXyoYs1+3eeN6CV9s7IOkeP44xII1 kX61gyXqHc6qVn4I7zWi8lPoTwBRHRqNY2NpuOVL9JoEw1Q8+KBQCBJ8WJPz6kFivqqF vpVo5U8gHIzPUz4DE4yDnO3f3jBYCZGZBvdUZvObpL0A1iyis0jxmhNxLIdQj9BsPJqF ABaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5UwbHV1wY9wTRH98jCnH3gmlSk1rVa3C7U6ZZbfROeg=; b=AC90Sqyj+zfAEYgu+g+k4EZAyKqhRGmwJK41JR0FNF955daxVmvX6YiUebIuJKMWjw hO/LVeN9jAt6gEyxrHjTE8Zh4dAMlGaUBifeO8A+crJUX2NSDPGZnfGev2VSIYUi7ETq phTmhGC3jA2kcfqRCFXOElAyHxTINeRCJcq7EI9Tw6l32AOpC9fZCfh2w85WY+6s0jnJ iILQNAcBpWhPgPp7kTUVCyOvPlHLBgdGH7iezxU5RobkydcxVxhpu5Q0QPYnHlLYyFUi SFztRCu8q2JEnutqK4GPs3nKL7d2/BZN/1rPz0hKYLWkSiPVbriTlBrzGOvA5+SczvKL Sr8w== X-Gm-Message-State: AMke39mtq/1VTf2eu9mnj1eMcgSa//f/GeQ6xoahr3lzLypdwYzSl/jUMRMG6ahRvGk+tbZKHooFSolDBjneOw== X-Received: by 10.107.47.195 with SMTP id v64mr413391iov.85.1486401461175; Mon, 06 Feb 2017 09:17:41 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.136.18 with HTTP; Mon, 6 Feb 2017 09:17:40 -0800 (PST) In-Reply-To: <148640102898.18999.14928493172416550288.idtracker@ietfa.amsl.com> References: <148640102898.18999.14928493172416550288.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Mon, 6 Feb 2017 12:17:40 -0500 X-Google-Sender-Auth: uFCHTdRLRIEtSyiMf2qMDJeCLG4 Message-ID: To: IETF Meeting Session Request Tool Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: session-request@ietf.org, Stephen Farrell , IETF OpenPGP , openpgp-chairs@ietf.org Subject: Re: [openpgp] openpgp - Not having a session at IETF 98 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:17:44 -0000 As you all can see, I recorded that we won't be meeting in Chicago, as there hasn't been any discussion on the mailing list. We're waiting for an updated spec that addresses open issues, so we can discuss that and see where we are. The chairs need to have a discussion with our responsible AD, and see whether we think this working group can actually get the document completed. Barry, as chair On Mon, Feb 6, 2017 at 12:10 PM, "IETF Meeting Session Request Tool" wrote: > > > Barry Leiba, a chair of the openpgp working group, indicated that the openpgp working group does not plan to hold a session at IETF 98. > > This message was generated and sent by the IETF Meeting Session Request Tool. > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sun Feb 12 16:59:38 2017 Return-Path: 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 7A11612950B for ; Sun, 12 Feb 2017 16:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 E-kDcRK18ryA for ; Sun, 12 Feb 2017 16:59:36 -0800 (PST) Received: from castro.crustytoothpaste.net (sandals-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3f1::2]) (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 2B6741294F0 for ; Sun, 12 Feb 2017 16:59:36 -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 D6138280AD for ; Mon, 13 Feb 2017 00:59:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1486947573; bh=L4kiSH1XE3U/V3nPt+lingAg/sPvC5oFdSAkwo+ynZw=; h=Date:From:To:Subject:From; b=bQEXEM4QeVIFvnh+9nEMcumk5MKhrQRWbVxRXWBmhAHASsPI8O4lSLfi4PC1+e2Wj ZfFTnu2vzRV6Al3PCKLsgqUxJaWuUwKwfgEbuugycV0uozEKqDUqz9zglJffblV3q8 JFB6ybFkjFJReesxoaOrWlWj2vh1GXy/DLxioK9l6ftzJoBDqUPvtSRL6BdBRC4k2b WjgsEWJtiLJyXwqI4SJbAxhVsn9CEPBks90/7wHmAe7tk7o6Le/Ao70Ym85gWgRnT9 5g0nrmsjVs1GziWs9rKsEtGpVT+cEHxPBxvPNttI7jsTrKXXDkJ/vsc5q4mEU5G1Iq JFuYgzz1gon1lChSxYvnIOLjFgP7BQH1z4njECaaS5699XdqHhbaqZdQ5ZM9hIHx2y uDUC28sjmEvRSlrPp33vWDd+opHfjBlMkXdrQp+2lHXElyWNnHMn/+kNQEzy0gu0/d 6VpHRIuQLXi614zR9KURWSMm2v+V4Z9puIaG5uWEZ90NQ/K+D+q Date: Mon, 13 Feb 2017 00:59:28 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: <20170213005928.2ytmjp3h2njyjcgy@genre.crustytoothpaste.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ybn4jj7mkssuc25a" 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: Subject: [openpgp] Pull request for 8-octet lengths X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:59:37 -0000 --ybn4jj7mkssuc25a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There was some question as to whether we should use four-octet or eight-octet lengths for signatures (or some other technique), as one might want to sign more the 2^32 bytes of data. I've submitted a pull request[0] to use eight-octet lengths for all signatures. I don't think the overhead of hashing an additional four bytes for short signatures will matter, and I feel that simply overflowing the existing four-byte counter could potentially collision issues down the line. Other opinions are welcomed. [0] https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/1 --=20 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 --ybn4jj7mkssuc25a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.18 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlihBPAACgkQv1NdgR9S 9ou1iQ/+OuJmnCJAxBOYKNA3pW/YgD7x0tjAO0FOXdpPT57FplHx7r4iWQcF2Gs9 YpPRQG9F9QDiZ7fpsxFpNIKUwFhf7kyAFEpUg7DM10ni3IeKx9uSY47VXahPfTlu vDRU6kds3GSH1pqgLi2IJ48OmsaceKertss1urnmxvq1J4/WpCX9g4JuiTvpifk3 f21cTPBYLJFM+TZ2m73mAxUwr4KfjcPwjaWxqyVX/dJdMGPRU3F2DjSQ9x2HbTAE aeRAH3hUhPdtSfzTu5lxkFEKDJ9UsxiKKBktnVVlG2cAeVc8zxNHrL8mNTFAl+DK GU2KOS9bQ/TVdDvkK1cew6H04Q2pUItwNEqUx1jwN3nKLRBMjVFIzGeDtdFuDbXl rr9809sUWc0OLyD6NkRlmycsbnqtLwj9ByZSDTMSr177dKpvoDYcQB4HEIXfZ+qS mRQ82EkcAxYT1ymoM7hlCsNOCMQzP3Ixkdif1j8GS0vMnkQHb1oxMCCzjNIYdJVJ 4BhAGoFfzVJmddx8gsMnKkfAqQ4R5n/Fa3GUtPQ+4tGbj6x/BQxrnGtpoXcZX7ek OYQ1lc1PIdJ0yY5jNrtgLI6rwBd1VRtXppzF9Gwa37kd5bC5XsWEriKeR5ZrmIsZ 989Ir8tmeuRqMPf8KI8XSYy3ak/dysxy33YlSR0rk63DUUh59fI= =YRop -----END PGP SIGNATURE----- --ybn4jj7mkssuc25a-- From nobody Sun Feb 12 17:07:07 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; 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" 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 01:07:05 -0000 --mk4uo3b4hwzjsqck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 --=20 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 --mk4uo3b4hwzjsqck Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.18 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlihBrIACgkQv1NdgR9S 9ouFURAAhVa3AvgoZ1aIVGcFt9Ycd/C1rSJy/v+Wllt9DvbW062ntkIekERMxJs8 2jtpq9sUg/KauzvHlFREP57skScvHs4TxMdWNHHtTrrG2YQB3v2diYaUZvpe3mFu PxxP0GvVo6Mu1LDaviQLxovm0EpfLBRj0vxPwoZLJ2UiWROnYWdz1yd2/S/mCHH6 37oC7bVG36Fmv1xXMW0A430W72fOISHtPLQnmXMs+sNM5/RfkgU+7jzZTwlytW0W jm/oe9noDqDQN6oVr7JmH1NTMPhZWdZ6uUWZAKc1bp2rg4Zd0LNlVgfi5A42czhB 8cam30Y3oim0Xfnu1C9XeiNZ17euTSQA38vi2O0Bag9W1QgCnH1Ebfw4f745HFjt 7g0iXQiHEp4ZKAikg/sRg4SFiSpUkKn5FyXHoLIFKHc4wpsD/yHRvf5evp1ca8n2 6hg4p/4kwBqog4MnxoAtNDAE8/LesfmCdcdPHwD6j8Kt2Qk+3JPIbVZttivAHwww R98k6+0UOB8J0CYoL6KX5io9Mpxjtv6psqpdQn+EOOTgp6uOEyGo/aNVnwdc6M4Y 8s4uN9PI2SfN7FXIOrOhJZ+988jVL9gFkjmJzsKjG0fZyiS/wAHHDm/BSoWXtWim cWmBYCjBLRxnYh6wjCf/vKBOfhnlr+38U246sma0L8gkhM0JK9M= =ZN31 -----END PGP SIGNATURE----- --mk4uo3b4hwzjsqck-- From nobody Mon Feb 13 17:09:55 2017 Return-Path: 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 63ABD129401 for ; Mon, 13 Feb 2017 17:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.588 X-Spam-Level: X-Spam-Status: No, score=-4.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 s_fyk4LtBwnz for ; Mon, 13 Feb 2017 17:09:52 -0800 (PST) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (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 AA1B4120726 for ; Mon, 13 Feb 2017 17:09:52 -0800 (PST) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OLC00900B410H00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Tue, 14 Feb 2017 01:09:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1487034591; bh=zM4sIkNBqQTlPlshO6qftau2Aqji8emmgEI4vjZbYKg=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=n8ZyCBNtImqbpqAEObaFnH2eXVtzkfUCt3xD1HjUPJ6xpR/5Yvbkg+2CToXhZTgcR MDuykOpLum/dp2qxEn1tMoMBurXIv7FE1/84CSYVbthRLJ+TLtotsZO9NDoMs6bzaP irQVWuB1O2ORFFTTZyAhGlon/LPzY0JRCXrLH1dljSMfabHLq3h9cqI2RaseGemmGE yQHg8l9N62jIFmORAxh6jIF0MT/9j6W1l/5SQgu5ruttiXlgf6NIRRMo32BIQDRJm7 nV+djX9MSYQOHAkYoDVB7/6T1/tFah121nQGhdnDFdgnlnh38yT9CbkcK0C6fgNMIt HRicWKq8ifQkQ== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OLC00NIVB8E0F40@st13p27im-asmtp004.me.com>; Tue, 14 Feb 2017 01:09:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-13_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702140010 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jon Callas In-reply-to: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> Date: Mon, 13 Feb 2017 17:09:49 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> To: "brian m. carlson" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:09:54 -0000 > On Feb 12, 2017, at 5:06 PM, brian m. carlson = wrote: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I've proposed this as a starting point and welcome further comments. I'll request that another mode than GCM be used. In particular, I = disagree with it being "uncontroversial." It's the most controversial = mode you could pick. GCM is very brittle. It breaks in very bad ways if you aren't careful = with nonces/tags. There are many cases of people misusing it and getting = worse than no security. I state that because if you *think* you're = getting authenticated data, but it's actually been altered in transit, = and that will likely cause issues in the receiving state machine. This paper is all about = real-world cases of unintentional misuse of GCM. Furthermore, the multiply in GHASH is slow in software. Yes, there are = hardware instructions in high-end Intel and ARM processors, but if you = do it on lower-end processors or in something like javascript, it's a = pain. If you have to conditionally do hardware or software, it makes = implementation more difficult. I think GCM is fine to use in some circumstances, like high-speed VPN = boxes, but it's the AEAD mode that comes from ACME. If you are Wile E. = Coyote it is going to blow up in your face. Perhaps most rigorously, the real problem with GCM is GHASH. Anything = with GHASH is worrisome. Your mention of alternatives was incomplete, so I'll bring alternatives = up. We all really want to use OCB. If you look at = which is Rogaway's = page on it. While it is patented, there are some broad license grants. = There's one for open source software, as well as one for non-military = software. He's also given one OpenSSL. I'll bet that if someone asked = him for a grant for the OpenPGP protocol, he'd probably do it. As it is, = the large-swath grants for it (open source, and non-military) suggest = that we could either say that's good enough for us or ask for another = grant. But if we don't want to, we don't want to. OCB is the mode = everyone really wants to use, but I don't want get wrapped around the = axle on the controversy here, either. Beyond OCB, though, there are a lot of alternatives: * CCM. CCM has been my go-to for AEAD in many cases. It is easy to = understand and works well. It is easy to get right. I think that this is = an important property, being easy to get right. Its major disadvantage, = being a two-pass algorithm, is not that bad for OpenPGP because we have = streaming packets in the core protocol. Nonetheless, Rogaway's own paper = about it (see the OCB link above for it) is not a bad paper, but = remember that Rogaway is arguing against CCM in favor of either OCB or = his own EAX. * ChaCha20+Poly1305. Many of the cool kids are using it. It's fast, = reasonably okay to implement, it's in TLS 1.3, and wouldn't be a bad = choice. The major criticism I can see is that ChaCha20 is a stream = cipher not a streaming mode on a block cipher (like AES or Twofish or = whatever). I think most of the legitimate criticisms of it are blunted = by its being used a lot in the TLS world. * SIV. SIV is another Rogaway mode, it's unencumbered, has resistance to = misuse, and I can't think of anything bad to say about it other than a = plea not to use the GCM version because GHASH. Many cool kids are using = it. * EAX. I tend to discount EAX because it's not OCB, not CCM (which was = created to be Not OCB), and not SIV. I wouldn't scream, though. I just = think that in this day, it doesn't have an advantage over any non-GCM = AEAD thing. * CTR+HMAC. Like you, I mention it for completeness. But while I think = that any of the above would be better, I think it is again better than = GCM. It's not sexy but it works, and it's harder to screw up than many = things. So to sum up, I think that GCM is actually controversial and dangerous = for generic use. Jon From nobody Mon Feb 13 17:13:46 2017 Return-Path: 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 92DE61294B3 for ; Mon, 13 Feb 2017 17:13:44 -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, SPF_PASS=-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 89fyUiQK2smV for ; Mon, 13 Feb 2017 17:13:43 -0800 (PST) Received: from castro.crustytoothpaste.net (sandals-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3f1::2]) (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 EAC03129506 for ; Mon, 13 Feb 2017 17:13:42 -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 C072C280AD for ; Tue, 14 Feb 2017 01:13:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1487034821; bh=Zzgf0345SmuHajy7HSvOLmDk0Eyl1EESvUO6qoNW0f4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OkZAmx/GHjYHGVxWqLyVxciVkXLb61aNfgyplnomIKGTihLGOjhnvGvFXu64vBCxX Clt0IE+FKvH5kR61qJtGt8K4GJJQqqwwMCgrqiNa0DYHdFf+2VlFKN90t+HAFM7XNs +iRLqjhOWG8YW/Z/BNXzCJpcwog1DbKVK//TBrt7kqXpUmbiEspVHYjcmSjkVpCliW +K8Uwq4r255relIT2tXo7OUm95iSiIJ2Jx38bbmOnqCk97gzuqEvR5ZL+/wP0zWEq7 8iGFqmgHjEqCWNt6vjXzz8FoNGoFOxZmWWgJeJdb85ck6buqWiuY+E0hftHPkiwhcl Pxkdw42aCTj5WR+rOovCQtCrKv+x6ozprNBrsNN5kd4ytB+NymfpOf0gEqgNPipW6x b2wBQbWYYE2g7xnvEMmkloV3GGBlKuzSFnPyKkDZTTE++cwJ4wk262c1yk+oQTQeaq XlJi+M44pKmRIJaABno9oH6E6MN8Njv1wqIXFJkoWm9AenYlsY8 From: "brian m. carlson" To: openpgp@ietf.org Date: Tue, 14 Feb 2017 01:13:32 +0000 Message-Id: <20170214011332.839171-1-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170213005928.2ytmjp3h2njyjcgy@genre.crustytoothpaste.net> References: <20170213005928.2ytmjp3h2njyjcgy@genre.crustytoothpaste.net> Archived-At: Subject: [openpgp] [PATCH] Specify eight-octet lengths for V5 signatures X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:13:44 -0000 --- middle.mkd | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/middle.mkd b/middle.mkd index 5182c7d..96be061 100644 --- a/middle.mkd +++ b/middle.mkd @@ -1654,7 +1654,7 @@ first the primary key and then the subkey being revoked. A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute -packet packet, without any header. A V4 certification hashes the +packet packet, without any header. A V4 or V5 certification hashes the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or @@ -1671,7 +1671,7 @@ unhashed subpacket data length value is set to zero. Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the -four-octet signature time. A V4 signature hashes the packet body +four-octet signature time. A V4 or V5 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public-key algorithm, the hash @@ -1683,6 +1683,11 @@ big-endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final six octets). +V5 signatures instead hash in a ten-octet trailer: the version of the +Signature packet, i.e., 0x05; 0xFF; and an eight-octet, big-endian +number that is the length of the hashed data from the Signature packet +(note that this number does not include these final ten octets). + After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and placed at the end of the Signature packet. -- 2.11.0 From nobody Mon Feb 13 17:24:32 2017 Return-Path: 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 60D8E129985 for ; Mon, 13 Feb 2017 17:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Zk5E59jNfO9f for ; Mon, 13 Feb 2017 17:24:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E8012996F for ; Mon, 13 Feb 2017 17:24:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 82446BE7B; Tue, 14 Feb 2017 01:24:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33WKPVayWjZX; Tue, 14 Feb 2017 01:24:25 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 95887BE79; Tue, 14 Feb 2017 01:24:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487035465; bh=QPKQHo8vgVJBo3V/0mxJv3aVCSzDJgj5tz+nypmLiyc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AQ5XdWedwAVNG40o2lqgxV77+jY0VIG4GU6CLTX9l7A5oCMKDyHbS4sbGWKtfIsJX gBdpVBLk0j+YTgiHEZa8mAaNDYhRBirKY3ZWiYtkExw/2Yc2tJpwBHK9rQoVhIyND3 DLyGiF1JhHwmpZkf2CxuQ9X4fmsznSCUwsBxvIhQ= To: Jon Callas , "brian m. carlson" References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Feb 2017 01:24:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GSjXh9VJ9BXm8XkffSJJ1cKqaDIGsjbxu" Archived-At: Cc: openpgp@ietf.org Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:24:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GSjXh9VJ9BXm8XkffSJJ1cKqaDIGsjbxu Content-Type: multipart/mixed; boundary="QnDqjBjcLwn9iXSRMJUhqb7jgtp0Mxwv3"; protected-headers="v1" From: Stephen Farrell To: Jon Callas , "brian m. carlson" Cc: openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Pull request for AEAD encrypted data packet with GCM References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> In-Reply-To: --QnDqjBjcLwn9iXSRMJUhqb7jgtp0Mxwv3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just on one point... On 14/02/17 01:09, Jon Callas wrote: > We all really want to use OCB. If you look at > which is > Rogaway's page on it. While it is patented, there are some broad > license grants. A recurring issue with OCB in other contexts has been that it it not only Rogaway's IPR that is at issue. Despite (what I think is) his very flexible and reasonable way of handling his own IPR, and even his efforts to get others to play ball, there are multiple other parties involved, not all of whom are IIUC equally reasonable (according to my personal view of what's reasonable). I don't know that that situation has resolved itself favourably in any case to date. I'd be happy if it had though, so please do follow up this with good news, if such exists. This issue was discussed on both the CFRG and TLS lists, maybe a year or two ago, so interested folks would benefit from checking those archives for OCB related threads. Cheers, S. PS: Note that I'm not stating any opinion pro- or contra- GCM nor any other AEAD construct here. --QnDqjBjcLwn9iXSRMJUhqb7jgtp0Mxwv3-- --GSjXh9VJ9BXm8XkffSJJ1cKqaDIGsjbxu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYolxIAAoJEC88hzaAX42imcAH/0+CcZOYVEvtWyMkgx6z4OjZ Uaarlh8Q9tu6M1X+khZnbUfuNenh8TNQGW/7qxyst7JrhFag0T1lNwHkdRjhgYIG XFaplJh0K9r9rDKK7YuqXBSSVgtYzIDUjOARboFwkAVWmAbGs3kVuPWEEOZxiepZ usTb4gr8TATU/JGQVtB57CTTx0z0yDuW8G3qqHJPeWM5ZZfnlfPrAArpQsKkPHAY bHxmj3jjec2/5m+kmNcO6KvtWBk+i+Bq5XeG8xU4DMLCtd9vvUKH4K4A1K+Fbln1 lEdD5hQ7cTdm/MBgHMFF2KItcoD7hSZ7EKRb5e9iugagixKPTbZzWPBiDvQe5ng= =XYrY -----END PGP SIGNATURE----- --GSjXh9VJ9BXm8XkffSJJ1cKqaDIGsjbxu-- From nobody Mon Feb 13 17:28:24 2017 Return-Path: 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 4E4841299FA for ; Mon, 13 Feb 2017 17:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 B4kxEhG0oeFX for ; Mon, 13 Feb 2017 17:28:21 -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 83520129998 for ; Mon, 13 Feb 2017 17:28:21 -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 A3A9B280AD; Tue, 14 Feb 2017 01:28:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1487035700; bh=8J2uFyXnxYM4dfgunZqm/N6DYBPTJkedGGt9tg5ULiw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BvQvQGXwOvee463ZJRK58kkT0JrjYqha4PS1+3R/nR4eBxxU2x/150EkIvGghtQFm 86Iw1uve6ph/fQWq+8fHXBjGWMyf4mtP9+sfHb6k7JH6RfkhN8MAUS5EFd2tQBUGhX mlrDipfGIsPDi5FNwmbncI5CVzBIuZE+ljml7xTsP0mlEnTnHwo5uQT79JlK5M4k+I 0GGLRc4DAAXbROwT2si8yqWcMF14CKLts11FXclD6NUevzOYxnTuUzWowndQCG3hLf yCgl2bFVL8lDa2FtPbKZDn143ZNCDzgBY8lEZ9sK7S37jdmvbRJFa1tHzLdDQpGI2q uzupNpE4lCqcBHwvcNXC34+BlG7L4eP82aM64T3yLfl3+O9SNWZS758nUULKeVmtY8 jsKy8C35Cqb0Y+M3oHy+kA5t0GQ0reAcTxWiJZ74X2CWGuSf3mikrP1tLEr4HlFI4a RcefjlhzrjkDEga2+FnVO9aqJEBC2F8lDtnTeajyrgr1iJhL9fu Date: Tue, 14 Feb 2017 01:28:17 +0000 From: "brian m. carlson" To: Jon Callas Message-ID: <20170214012816.w5tyv3jmwmjb6rtp@genre.crustytoothpaste.net> References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fys2cy2bdpxwm72x" Content-Disposition: inline In-Reply-To: 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: Cc: openpgp@ietf.org Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:28:23 -0000 --fys2cy2bdpxwm72x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 13, 2017 at 05:09:49PM -0800, Jon Callas wrote: > Your mention of alternatives was incomplete, so I'll bring alternatives u= p. >=20 > We all really want to use OCB. If you look at which is Rogaway's page on it. While it is patent= ed, there are some broad license grants. There's one for open source softwa= re, as well as one for non-military software. He's also given one OpenSSL. = I'll bet that if someone asked him for a grant for the OpenPGP protocol, he= 'd probably do it. As it is, the large-swath grants for it (open source, an= d non-military) suggest that we could either say that's good enough for us = or ask for another grant. But if we don't want to, we don't want to. OCB is= the mode everyone really wants to use, but I don't want get wrapped around= the axle on the controversy here, either. >=20 > Beyond OCB, though, there are a lot of alternatives: I think OCB is a non-starter because of the patent. It doesn't matter what the patent situation actually *is*. It matters what Red Hat's lawyers and the lawyers of thousands of companies worldwide think it *might be*. Red Hat refused to implement ECC for a long time because they thought it *might* have potential patent problems, and the uncertainty was enough to seriously delay modern ECC support on a significant portion of servers. I don't want to write a spec that is going to be unusable or less usable because of the patent. OCB is also not implemented in most crypto libraries (for the above reason). If we have people writing code in web browsers and scripting languages, we want something that Web Crypto and OpenSSL are going to support. Otherwise, we're going to have people writing crypto implementations in JavaScript and Ruby and whatnot, and those aren't going to be side-channel safe. People are already doing this, so we should consider it as a use case. > * ChaCha20+Poly1305. Many of the cool kids are using it. It's fast, reaso= nably okay to implement, it's in TLS 1.3, and wouldn't be a bad choice. The= major criticism I can see is that ChaCha20 is a stream cipher not a stream= ing mode on a block cipher (like AES or Twofish or whatever). I think most = of the legitimate criticisms of it are blunted by its being used a lot in t= he TLS world. That's why my proposal (which I will send a patch to the list for shortly) proposed an octet for AEAD algorithm. We can implement ChaCha20 as a cipher and Poly1305 as an AEAD algorithm. I support doing this, but doing just ChaCha20-Poly1305 excludes a secure implementation of all the block ciphers that we currently have. We need something that works with AES. > * CTR+HMAC. Like you, I mention it for completeness. But while I think th= at any of the above would be better, I think it is again better than GCM. I= t's not sexy but it works, and it's harder to screw up than many things. That's why I like it. Assuming you have a constant time AES implementation, you can implement CTR and HMAC in constant time in almost any language. Those algorithms are also implemented in most libraries. --=20 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 --fys2cy2bdpxwm72x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.18 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAliiXTAACgkQv1NdgR9S 9ovbMg//f31OldrhdY8zm4CYZFC1x9jtUhOJkFIj/K28fr6JCkVD8tYYHib3EXre jxnsukoGeejYFiMgVbQxPY7JpaJmXy1A1ExkAbEJ5YssxlO4Sqg6RlbUVZLYaAju aYcbnIQ3gn1n389YRJAJKFfyBsXVxJ0uDq5Rj8YrZ6SwawnTL5sVzEmFXtTZenZU h8RuOkeRa/Mz/+wDi7tvByoK6RuGK4JxDAIspVpGmlsoO8Juln/j5g5C9KVmWukI FwfGMkgwhMx+n4f5fkD1UnGkFa3QU8P3LZXbLHN5WqJ96rD7A9h07R2/O7t5gXaW 1uwjnGlDcaZn1empd8RC2jARL3z6yVlPgiNSTPcl99Htnr8HTBJdLIEXcrPlBTF1 NwgqzKS8woKLIGYsbViFK31cj2/A7GzD+AjA6KqQfdHSXw/xqUhrUi1KOWg7YSbc Of8BbJhMo3sRWarrmLyx4DbsP6adu0gg9oBJqM1rfNzh3N/bhPZi5G0863iH2MX+ DYATyX+DgYeSFURnLsRH0NRku6PWqIqG+c+dhiAWVXrQZc6m6ph7QVfHuiXkX1gE 0ADkWVESm5TuFGau14K8qHci+v00A/k+eBlzJMFtFBFPkSIegCuNLVHx4hU5hbSG Wvjy5yTeQzZBl5vVaOXwNIvJfPeHAp56NE2GEMnvBa5LNDsVPZM= =ieBN -----END PGP SIGNATURE----- --fys2cy2bdpxwm72x-- From nobody Mon Feb 13 17:30:17 2017 Return-Path: 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 528BE129960 for ; Mon, 13 Feb 2017 17:30:16 -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, SPF_PASS=-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 Eqy6OciBpK2D for ; Mon, 13 Feb 2017 17:30:15 -0800 (PST) Received: from castro.crustytoothpaste.net (sandals-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3f1::2]) (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 1BB3B12998C for ; Mon, 13 Feb 2017 17:30:11 -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 6871E280AD for ; Tue, 14 Feb 2017 01:30:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1487035810; bh=Sp71P1V2rSBqF0xh2cIGMVWkZhLp01wgrcD4odeZMUI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kdJe8TQYkM+data1wBYJIg61tRpG/iuzK3eIQRgYzdrJeVL6SnCPZaAmARiliSe8H wU887EhvUWT++DoMASx2IBqOM2AuZV+OGuprjxswah4ReteGyMzn9iiV1wfL4c35NQ VsbDBaLn/P3iEaNFUJ+/HH4RUjfeBSVRZu4W4gdWAipHZvhtMJZa8JzZghNKJ8TfT2 ggT/phWN9U8aV3C6Ia3WqPgDM4IwTQ5rvsyjhawcx/LEnjv/PKHGj8pCYRuuNjfjjS hLBgL19DzOAebz37ND30NeRtYyxHMxpIvZnAWM6JqS1St9ykLGawn7HJYGvB8WZp9q pLuQpTaT008VIxZ0eHQM7SFSn85KF3bqIXwqqpKf9npiCzetH0e3HpfTOl6EG+NsIu sw7Mk1FckJiaHyUJLgx29bQ+UW9dvqX1Ne77FlDFP5zL43g0UE9gm3kJoU2PUyEbQg VJu+Pg6tOmCcDg2YAdKon/3t1QpXAAPDEf46lmIKBDlp4Upz7R8 From: "brian m. carlson" To: openpgp@ietf.org Date: Tue, 14 Feb 2017 01:29:53 +0000 Message-Id: <20170214012953.839519-1-sandals@crustytoothpaste.net> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> Archived-At: Subject: [openpgp] [PATCH] Add 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:30:16 -0000 --- middle.mkd | 46 ++++++++++++++++++++++++++++++++++++++++++++++ template.xml | 11 +++++++++++ 2 files changed, 57 insertions(+) diff --git a/middle.mkd b/middle.mkd index 5182c7d..e842938 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2483,6 +2483,42 @@ packet length. The reason for this is that the hashing rules for modification detection include a one-octet tag and one-octet length in the data hash. While this is a bit restrictive, it reduces complexity. +## {5.14} AEAD Encrypted Data Packet (Tag 18) + +This packet contains data encrypted with an authenticated encryption and +additional data (AEAD) construction. When it has been decrypted, it +will typically contain other packets (often a Literal Data packet or +Compressed Data packet). + +The body of this packet consists of: + + * A one-octet version number. The only currently defined value + is 1. + + * A one-octet cipher algorithm. + + * A one-octet AEAD algorithm. + + * An initialization vector of size specified by the AEAD algorithm. + This value MUST be unique and it MUST be unpredictable. + + * Encrypted data, the output of the selected symmetric-key cipher + operating in the given AEAD mode. + + * The authentication tag for the AEAD mode. + +The AEAD construction is given the packet header, version number, cipher +algorithm octet, and AEAD algorithm octet as additional data. + +### {5.14.1} Galois Counter Mode + +The only currently defined AEAD algorithm is Galois Counter Mode +[](#GCM). This algorithm can only use block ciphers with 16-byte +blocks. The initialization vector is 12 bytes long. + +The security of GCM requires that the counter is never reused, hence the +requirement that the initialization vector be unique. + # {6} Radix-64 Conversions As stated in the introduction, OpenPGP's underlying native @@ -3014,6 +3050,16 @@ algorithm. Implementations MUST implement SHA-1. Implementations MAY implement other algorithms. MD5 is deprecated. +## {9.5} AEAD Algorithms + + ID Algorithm + -------- --------- + 1 GCM [](#GCM) + 100--110 Private/Experimental algorithm + +Implementations MUST implement GCM. Implementations MAY implement +other algorithms. + # {10} IANA Considerations OpenPGP is highly parameterized, and consequently there are a number diff --git a/template.xml b/template.xml index 9ea1582..f52521e 100644 --- a/template.xml +++ b/template.xml @@ -144,6 +144,17 @@ + + + Recommendation for Block Cipher Modes of Operation: + Galois/Counter Mode (GCM) and GMAC (SP 800-38D) + + NIST + + + + + Handbook of Applied Cryptography -- 2.11.0 From nobody Mon Feb 13 17:32:52 2017 Return-Path: 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 1E43D12951F for ; Mon, 13 Feb 2017 17:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 KmolBZAMvdNb for ; Mon, 13 Feb 2017 17:32:49 -0800 (PST) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (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 42A99129462 for ; Mon, 13 Feb 2017 17:32:49 -0800 (PST) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OLC00V00C9YGZ00@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Tue, 14 Feb 2017 01:32:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1487035968; bh=PZLTmodfUkT5ZxYSOK5CJhUJR3OsecRv9X1QCBCghF4=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=kS/re5dVFQARg1yzhFD2SbMGZxCZwpKZkPkq8luDqqzswa7FZPt8UomEOouc/h2B6 k+OtvNfYBCYb/ZSfwikmoo4SxjNdYeC40pEvfdtmFQ3nt2fe8EBatQTtzCLo3gtukh KmzdOn8+OAfZNPpIhYGwCnKypMCvgwgIYuvieZwRRB3NfbAa/KuzZYIeid6VacNkYV e/T0IqtBZiJ3dkfoVNUv9cmbZC5tSXKYoSKlOYIGf4SVQMGOHe8iAkWPHSBtEQIz8C OvxPw6oVLxZQLb3Qkre8+sEuanBvHfk9uA4UNewj4tNWwimt1/UUNeAWNxb0ZQmvCE 6YlqAuPIVWxFg== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OLC00R88CAM9X00@st13p27im-asmtp003.me.com>; Tue, 14 Feb 2017 01:32:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-14_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702140014 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jon Callas In-reply-to: Date: Mon, 13 Feb 2017 17:32:45 -0800 Content-transfer-encoding: quoted-printable Message-id: <32AF7F3F-5FDF-418F-8124-0FDB7B24FE18@icloud.com> References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> To: Stephen Farrell X-Mailer: Apple Mail (2.3259) Archived-At: Cc: openpgp@ietf.org, "brian m. carlson" , Jon Callas Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:32:50 -0000 > On Feb 13, 2017, at 5:24 PM, Stephen Farrell = wrote: >=20 > A recurring issue with OCB in other contexts has been that it > it not only Rogaway's IPR that is at issue. Despite (what I > think is) his very flexible and reasonable way of handling his > own IPR, and even his efforts to get others to play ball, there > are multiple other parties involved, not all of whom are IIUC > equally reasonable (according to my personal view of what's > reasonable). >=20 > I don't know that that situation has resolved itself favourably > in any case to date. I'd be happy if it had though, so please > do follow up this with good news, if such exists. >=20 > This issue was discussed on both the CFRG and TLS lists, maybe > a year or two ago, so interested folks would benefit from > checking those archives for OCB related threads. >=20 > Cheers, > S. >=20 > PS: Note that I'm not stating any opinion pro- or contra- GCM > nor any other AEAD construct here. I have no disagreement with this. I am constantly pained that this is a = mess, because OCB *is* what we all really want to use. Jon From nobody Mon Feb 13 18:05:40 2017 Return-Path: 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 DB8071294BA for ; Mon, 13 Feb 2017 18:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 Tx19KJgYLovZ for ; Mon, 13 Feb 2017 18:05:39 -0800 (PST) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (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 DF26A1293FF for ; Mon, 13 Feb 2017 18:05:38 -0800 (PST) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OLC00200DPS4D00@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Tue, 14 Feb 2017 02:05:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1487037938; bh=+W2ozbKKDQMy85QQTZZseVQGOJm4FnCM+9nBHwJWr58=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=LhaS3vCWA9aYVKuDmrybez1m+3wtQtuwV7NTpVYQZ2CPJx2oviUuWNWVBlW7RfR0l YcJbmauBX5Pza1unJoMTcrzwV/NIiKnZiWdl3mhXTtq0CIkgKBAzCMRu0Q6Ec6cxLr 93aSc/eePlRjopEQUkAvJYdxZQ5ochukzbhHO531DkGdQsCCMBH5H0JYZIl0XvUlKF cpTS69FxoM/RDkg32B6uCswue6N+msmNzO/VWk+S1inlLPltU6gvfKXFB/ddb3xg3N tkjxWwHWkw5hzwah/TKkduKTftjMcnV24SnVSviGLC4fq4WoXGOi0HmygVIO1GKQ8K 388k54/rXK6pA== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OLC00RM9DTC9X10@st13p27im-asmtp003.me.com>; Tue, 14 Feb 2017 02:05:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-14_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702140021 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jon Callas In-reply-to: <20170214012816.w5tyv3jmwmjb6rtp@genre.crustytoothpaste.net> Date: Mon, 13 Feb 2017 18:05:34 -0800 Content-transfer-encoding: quoted-printable Message-id: <2DD2082E-905A-44F3-AF7B-E6262C71593E@icloud.com> References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> <20170214012816.w5tyv3jmwmjb6rtp@genre.crustytoothpaste.net> To: "brian m. carlson" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 02:05:40 -0000 > On Feb 13, 2017, at 5:28 PM, brian m. carlson = wrote: >=20 [OCB discussion removed because we're all in violent agreement.] >> * ChaCha20+Poly1305. Many of the cool kids are using it. It's fast, = reasonably okay to implement, it's in TLS 1.3, and wouldn't be a bad = choice. The major criticism I can see is that ChaCha20 is a stream = cipher not a streaming mode on a block cipher (like AES or Twofish or = whatever). I think most of the legitimate criticisms of it are blunted = by its being used a lot in the TLS world. >=20 > That's why my proposal (which I will send a patch to the list for > shortly) proposed an octet for AEAD algorithm. We can implement > ChaCha20 as a cipher and Poly1305 as an AEAD algorithm. I support = doing > this, but doing just ChaCha20-Poly1305 excludes a secure = implementation > of all the block ciphers that we currently have. We need something = that > works with AES. Forgive my being out of the loop on this and behind in document reading. 4880 uses CFB implicitly with two flavors (regular and with MDC). = Historically, OpenPGP leaves lots of parameterization around which is = great for experimentation, but hell on test matrixes. One could = parameterize a new packet in which there was a cipher parameter and an = integrity parameter. Thus, one could have a the matrix [AES(key size), = Twofish(key size), ...., whatever; CCM, SIV, HMAC, ...]. (The clever = reader might note that HMAC leads to its own parameter.) Or one could = have a parameter for a full thing like AES128-SIV, or = AES256-HMAC-SHA512. I recommend the latter, myself.=20 In that case, just pick decent parameters on ChaCha20+Poly1305 and be = done. This is slightly important because this would be the first time = OpenPGP used a stream cipher per se. Historic note: OpenPGP dates from a time when there were a lot of good = arguments for a lot of options. Okay, there were better arguments than = there are now. :) You know, should we use IDEA, CAST5, or Blowfish? = Should we allow DSA to be used RIPEMD-160 because SHA-1 was created by = the NSA and some people think it's backdoored. We also in those days = wanted maximum consensus on getting 2440 done as fast as possible. That = led to a lot of parameters and then contraction of those parameters = later when people never implemented the algorithm they really wanted. I = think this is an opportunity to collapse option explosion by just having = AE suite parameters. This would allow some generosity in parameters = without total option explosion. >=20 >> * CTR+HMAC. Like you, I mention it for completeness. But while I = think that any of the above would be better, I think it is again better = than GCM. It's not sexy but it works, and it's harder to screw up than = many things. >=20 > That's why I like it. Assuming you have a constant time AES > implementation, you can implement CTR and HMAC in constant time in > almost any language. Those algorithms are also implemented in most > libraries. This is also an argument in favor of CCM, SIV, and perhaps others. One final thing that just occurred to me. If we really, really want this = to preserve some OpenPGP goodness, there would also be a preference = packet to allow someone to state what they do and don't speak.=20 Jon From nobody Mon Feb 13 18:26:57 2017 Return-Path: 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 9AC4912945E for ; Mon, 13 Feb 2017 18:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 xBXVtFflFzuh for ; Mon, 13 Feb 2017 18:26:54 -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 030D412945C for ; Mon, 13 Feb 2017 18:26:54 -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 D4395280AD; Tue, 14 Feb 2017 02:26:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1487039211; bh=W+uKOon6yQ/MTukEv4RifzP2wssY0C0Spu6Un6IZN68=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=F1MvH5v+s1gzFRZa9pG7/etoXD7lPXWk/2WqbTCs7kBNGDIoAXV7MWBeWgsZRYLqF R845d8whOxXq/Ty8znIHEoOcTsJ6PZGVjjb3q737rDHiJQyahO0LGdeIhjRVExpg5E iESpjgaukZH1Zcbkq17kAMRT6TMJk3b/FN6meuF2tYsa5Bf77AHN4Hm9BRyc+beeFu GOCdt9EXp0mVQQehjMrOd0HC6IlsH8OMFQ4D954fu7K8y9jvn8yLILw/4dhYM56Tv4 IuBv2cYUBTn/TR0rW9LVeQhLhmFddRvdzACT+lWzAzqky9BD/PAVG11QKHsT3pJ0cd sS5yX/3YjpXS1WmJbAsOEObkLgatYoQSi2CIpcXILPoRP8hVa2z3v5X2bSTUfLVKrm s935lcZn6aA8zvbboukkUNwynanefCYXNWwUTzLuB/i8TAz6YF705HD74GvclCng/I WxaA2RRhEWd94q9Vze7Q8XbUjKrR7317VMYiuGvul86m3lmzEaz Date: Tue, 14 Feb 2017 02:26:45 +0000 From: "brian m. carlson" To: Jon Callas Message-ID: <20170214022645.htrsigltdubrly37@genre.crustytoothpaste.net> References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> <20170214012816.w5tyv3jmwmjb6rtp@genre.crustytoothpaste.net> <2DD2082E-905A-44F3-AF7B-E6262C71593E@icloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="agazaxkeichqll3z" Content-Disposition: inline In-Reply-To: <2DD2082E-905A-44F3-AF7B-E6262C71593E@icloud.com> 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: Cc: openpgp@ietf.org Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 02:26:55 -0000 --agazaxkeichqll3z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 13, 2017 at 06:05:34PM -0800, Jon Callas wrote: >=20 > > On Feb 13, 2017, at 5:28 PM, brian m. carlson wrote: > >=20 > > That's why my proposal (which I will send a patch to the list for > > shortly) proposed an octet for AEAD algorithm. We can implement > > ChaCha20 as a cipher and Poly1305 as an AEAD algorithm. I support doing > > this, but doing just ChaCha20-Poly1305 excludes a secure implementation > > of all the block ciphers that we currently have. We need something that > > works with AES. >=20 > Forgive my being out of the loop on this and behind in document reading. >=20 > 4880 uses CFB implicitly with two flavors (regular and with MDC). Histori= cally, OpenPGP leaves lots of parameterization around which is great for ex= perimentation, but hell on test matrixes. One could parameterize a new pack= et in which there was a cipher parameter and an integrity parameter. Thus, = one could have a the matrix [AES(key size), Twofish(key size), ...., whatev= er; CCM, SIV, HMAC, ...]. (The clever reader might note that HMAC leads to = its own parameter.) Or one could have a parameter for a full thing like AES= 128-SIV, or AES256-HMAC-SHA512. I recommend the latter, myself.=20 >=20 > In that case, just pick decent parameters on ChaCha20+Poly1305 and be don= e. This is slightly important because this would be the first time OpenPGP = used a stream cipher per se. My patch implements exactly that: a cipher byte, and an AEAD algorithm byte (it uses GCM, but it sounds like we want to change that). I feel like this provides us the flexibility we need without providing too many options, especially since I get the impression we may want both block and stream ciphers). If we did CTR+HMAC, I'd propose CTR+HMAC-SHA512 and CTR+HMAC-SHA-3-512 as the AEAD algorithms (just hardcoding those as AEAD algorithm bytes). If we did EAX or SIV, that would logically be the AEAD algorithm. If we additionally did ChaCha20, I'd define Poly1305 as the AEAD algorithm in the TLS way. I was not considering allowing further parameterization beyond that point, as that's a great way to let people pick bad options. We do need to preserve the existing cipher byte values for AES Key Wrap in coordination with ECDH, though. > Historic note: OpenPGP dates from a time when there were a lot of good ar= guments for a lot of options. Okay, there were better arguments than there = are now. :) You know, should we use IDEA, CAST5, or Blowfish? Should we all= ow DSA to be used RIPEMD-160 because SHA-1 was created by the NSA and some = people think it's backdoored. We also in those days wanted maximum consensu= s on getting 2440 done as fast as possible. That led to a lot of parameters= and then contraction of those parameters later when people never implement= ed the algorithm they really wanted. I think this is an opportunity to coll= apse option explosion by just having AE suite parameters. This would allow = some generosity in parameters without total option explosion. I think we're in agreement. > >> * CTR+HMAC. Like you, I mention it for completeness. But while I think= that any of the above would be better, I think it is again better than GCM= =2E It's not sexy but it works, and it's harder to screw up than many thing= s. > >=20 > > That's why I like it. Assuming you have a constant time AES > > implementation, you can implement CTR and HMAC in constant time in > > almost any language. Those algorithms are also implemented in most > > libraries. >=20 > This is also an argument in favor of CCM, SIV, and perhaps others. I think the two-pass nature of CCM is undesirable, but I'd be fine with EAX or SIV. I feel confident I could implement those in a constant time manner in a variety of languages given a constant-time AES-ECB and AES-CTR. --=20 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 --agazaxkeichqll3z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.18 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAliiauUACgkQv1NdgR9S 9osIHhAAxfnnmzUErxAzdzZkXdNqPYTlhkfAOkdYqWCXW8Ca5JEZZxoXg+EbQCrh vHSerbaSwmVrR7XzFf4cMXFBjC25VoHLczPZEwxftXqPv8ekZqupw6U4fwys7HOy +jy+NXYJ8Mnq2MaoU0nEUGcIS6aZWLifuMZULhCFXJ5hdgEE7l9wqES8wOOiim4R Z0FMxNkxCLAoZ7FW/sBomQ78WC5LgklHJu2Yd36Dp1PAMTpq1NORIU+VRNkWJmWh dACSVhq+KIvLsfqyeZ6TrQYyx0VKeOgDe55RCceAjnxrj4YSFLRtk7LgadyzQ1EL s8A6ycYXh0dtP+UfNfBleGv7cmaC8ar3aptKm4rfrSJaiRGonJZtKo9pnGzdKBHf UATrspagkGGQVp5ASWO6fX6KLolQPqZno00YA7Sw8uTvmHNT1lVqJgZraqXT0mFz N5n5z8BUAriTt2jrI6eiMUePdtTT12US/sxe2MhIJRzWoEs90sVj5xeKF4Ly25oJ LOEri/xHO5KJb26eZac1YDyMV6K+47hESJVbM2aoS6Np9wJ3ANASkyR4KPCOFNuk P6JxE0mKkQSomh7+hd7R9g2MWo163EzPliZwHnPf62TsLMtundzXFoyigfoSZYXS MCEDaAnf+9bF5mnlemQ3uPF0tqivnF/NKAebDXiO8yEYsQWYrB8= =MPTG -----END PGP SIGNATURE----- --agazaxkeichqll3z-- From nobody Tue Feb 14 00:32:32 2017 Return-Path: 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 8D1BE1204D9 for ; Tue, 14 Feb 2017 00:32:31 -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 19g-SL0fsIqI for ; Tue, 14 Feb 2017 00:32: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 AFD0612947A for ; Tue, 14 Feb 2017 00:32:29 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1cdYXD-0002lB-N4 for ; Tue, 14 Feb 2017 09:32:27 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1cdYUm-0008QZ-6S; Tue, 14 Feb 2017 09:29:56 +0100 From: Werner Koch To: "brian m. carlson" References: <20170213005928.2ytmjp3h2njyjcgy@genre.crustytoothpaste.net> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "brian m. carlson" , openpgp@ietf.org Date: Tue, 14 Feb 2017 09:29:55 +0100 In-Reply-To: <20170213005928.2ytmjp3h2njyjcgy@genre.crustytoothpaste.net> (brian m. carlson's message of "Mon, 13 Feb 2017 00:59:28 +0000") Message-ID: <871sv1yy2k.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=red_noise_pre-emptive_Freeh_S_Box_industrial_intelligence_Mena_SCUD="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Pull request for 8-octet lengths X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 08:32:31 -0000 --=red_noise_pre-emptive_Freeh_S_Box_industrial_intelligence_Mena_SCUD= Content-Type: text/plain Hi Brian, thanks for posting the text. On Mon, 13 Feb 2017 01:59, sandals@crustytoothpaste.net said: > There was some question as to whether we should use four-octet or > eight-octet lengths for signatures (or some other technique), as one > might want to sign more the 2^32 bytes of data. I've submitted a pull > request[0] to use eight-octet lengths for all signatures. Although 64 bit numbers are often not easy to handle on small systems it will be easy for such implementations to hash the required extra bytes (thanks to Big Endian). This is an easy and straightforward change. Unless someone objects, I will add this to the next draft. Salam-Shalom, Werner --=red_noise_pre-emptive_Freeh_S_Box_industrial_intelligence_Mena_SCUD= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWKLAAwAKCRD/gK6dHew1 jdl+AP9An9iHT4qSDg1/YH2aNkRVycG+Pn4sxlwf+jYvC0qeYAEAkQQeL3G7d2a3 e8C5BCuvAt7z+15Y/ALyhGBvpYxZnwk= =UZ+Y -----END PGP SIGNATURE----- --=red_noise_pre-emptive_Freeh_S_Box_industrial_intelligence_Mena_SCUD=-- From nobody Tue Feb 14 00:52:31 2017 Return-Path: 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 B3E25129A0D for ; Tue, 14 Feb 2017 00:52:30 -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 zy09dSvbDtIV for ; Tue, 14 Feb 2017 00:52: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 881731299D3 for ; Tue, 14 Feb 2017 00:52:29 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1cdYqa-00030e-2Y for ; Tue, 14 Feb 2017 09:52:28 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1cdYnm-00005K-Ud; Tue, 14 Feb 2017 09:49:34 +0100 From: Werner Koch To: Jon Callas References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net> <32AF7F3F-5FDF-418F-8124-0FDB7B24FE18@icloud.com> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Jon Callas , Stephen Farrell , openpgp@ietf.org, "brian m. carlson" Date: Tue, 14 Feb 2017 09:49:34 +0100 In-Reply-To: <32AF7F3F-5FDF-418F-8124-0FDB7B24FE18@icloud.com> (Jon Callas's message of "Mon, 13 Feb 2017 17:32:45 -0800") Message-ID: <87wpctxild.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=pre-emptive_Fortezza_LLNL_MP5K-SD_diwn_cracking_Blowpipe_Syria=Ft._B"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Cc: openpgp@ietf.org, "brian m. carlson" , Stephen Farrell Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 08:52:31 -0000 --=pre-emptive_Fortezza_LLNL_MP5K-SD_diwn_cracking_Blowpipe_Syria=Ft._B Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 14 Feb 2017 02:32, joncallas@icloud.com said: > I have no disagreement with this. I am constantly pained that this is a m= ess, because OCB *is* what we all really want to use. From=20our experience with adding the MDC feature to OpenPGP we known that it will take several years until the majority of code has been upgraded to make use of a new feature. The mentioned non-Rogaway patents were filed around 2001 and thus will expire 4 to 7 years. Which would match the time I expect to get OCB mode actually deployed (or any other new mode). Sure there are also follow up patents but given that they are owned by IBM they may even be an advantage against patent trolls. But this has likely already been discussed in the context of TLS. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=pre-emptive_Fortezza_LLNL_MP5K-SD_diwn_cracking_Blowpipe_Syria=Ft._B Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWKLEngAKCRD/gK6dHew1 jYr9AQC4aKCf/Irh3fG8Ga9tHwoerESLpeu7tE80O1gCsA47gQEA2EGJt4hrrwsy edjj/g/9i8Ph/MDGTe+Rud3sAzYXdgs= =o0je -----END PGP SIGNATURE----- --=pre-emptive_Fortezza_LLNL_MP5K-SD_diwn_cracking_Blowpipe_Syria=Ft._B-- From nobody Tue Feb 14 01:22:32 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 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" , Jon Callas Date: Tue, 14 Feb 2017 10:17:42 +0100 In-Reply-To: (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: Cc: Jon Callas , "brian m. carlson" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 09:22:31 -0000 --=red_noise_Skipjack_John_Kerry_assassination_Mossad_high_security_ass Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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? =20 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. =20=20=20 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 =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=red_noise_Skipjack_John_Kerry_assassination_Mossad_high_security_ass Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWKLLNwAKCRD/gK6dHew1 jaYhAP9qjklOnQ6vOv48hCkWAgW10/5GJOvI8mmfvTUXScBKuQD/XKpr6JE/MwgO y3k/iGH4eAgjfSIOgjnSOTQ+jc0yNAs= =5gai -----END PGP SIGNATURE----- --=red_noise_Skipjack_John_Kerry_assassination_Mossad_high_security_ass-- From nobody Tue Feb 14 03:30:33 2017 Return-Path: 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 475D81295D5 for ; Tue, 14 Feb 2017 03:30:33 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org 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 TCe4pj83kyfi for ; Tue, 14 Feb 2017 03:30:31 -0800 (PST) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (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 23589129581 for ; Tue, 14 Feb 2017 03:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:To:From; bh=SBIdhcpDW6jz3fnJxinvmN6o69dlN2Tcb4fycSmo5LQ=; b=sO0fjBMRzOCgUiNW/4Adam3MKMrQyo0G1zKPLOEB7BJOekbPoDAxNA1cFR1meKjnqlwslO5NaMe5oQ6l5cMpZY6TFAj/y+xltb/g7s+rqX4QrMlr908NplTRxTehB1oZxtMBa7knnXokd4rqPn5txuXzVRHXWUiPlVVhGaczw2E8PinUNYG02MqYVNE53KL23QA7/OO4RRfyraQ7obA/HdOSc5V6fVTikofmipwKTXkw7esVVfrZ4tBS/KlWvwrfHpbQPPh7GD7PcRn0U/mrFcA6/HfCNVpZZrIElkbIRzIj55iNnNRPfVtpSd0ntz/Rf2SFobz8qHJAK/CGeL0yqg==; Received: from z244078.dynamic.ppp.asahi-net.or.jp ([110.4.244.78] helo=c720.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cdbJU-0008Gl-OE; Tue, 14 Feb 2017 12:30:30 +0100 Received: by c720.gniibe.org (sSMTP sendmail emulation); Tue, 14 Feb 2017 20:30:19 +0900 From: NIIBE Yutaka To: Taylor R Campbell , openpgp@ietf.org In-Reply-To: <20170111143703.593E6603C5@jupiter.mumble.net> References: <20170111143703.593E6603C5@jupiter.mumble.net> Date: Tue, 14 Feb 2017 20:30:19 +0900 Message-ID: <87y3x9yppw.fsf@fsij.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] patch for EdDSA key packet formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 11:30:33 -0000 Hello, Taylor R Campbell wrote: > The current text describing the EdDSA secret key packet format is > wrong (it is not used as a scalar at all), and the text describing the > public key packet format is confusing (can't find the notation Q > anywhere, and it matches neither the EdDSA papers nor the CFRG EdDSA > draft). I agree these points. But, I'm not sure the fixes in the patch are good enough. In the patch: > From: Taylor R Campbell > Date: Wed, 11 Jan 2017 14:21:13 +0000 > Subject: [PATCH] Fix EdDSA secret key packet format with reference to CFRG > notation. > > What is stored is *not* a scalar; it is a b-bit secret input to a > 2b-bit hash function that expands it into > > (a) the b-bit secret scalar a, giving the public key A = a B, where B > is the standard base point; and > (b) the b-bit nonce PRF key. > > While here, clarify EdDSA public key packet format with reference to > CFRG notation too. I agree these are correct and reference to CFRG notation is good. Well, Simon's is now RFC8032: https://datatracker.ietf.org/doc/rfc8032/ Here are my comments for the fixes. > diff --git a/middle.mkd b/middle.mkd > index 5182c7d..905bde1 100644 > --- a/middle.mkd > +++ b/middle.mkd > @@ -1936,8 +1936,9 @@ A version 4 packet contains: > - the octets representing a curve OID, defined in > section NN{FIXME}; > > - - a MPI of an EC point representing a public key Q as described > - under EdDSA Point Format below. > + - a MPI, encoded as described under EdDSA Point Format, of an EC > + point A, in the notation of [](#I-D.irtf-cfrg-eddsa), > + Section 3.2 "Keys". I think that the expression "an EC point A" would not be good. In RFC 8032, Section 3.1 "Encoding" explains about ENC(), the little-endian encoding, and Section 3.2 "Keys" says: The EdDSA public key is ENC(A). ... where A is an EC point. We put the prefix 0x40 to ENC(A), it is not entirely same of the notation of Section 3.2 "Keys". Sorry, as I am not good in English, I don't have my own proposal. > Algorithm-Specific Fields for ECDH keys: > > @@ -2034,8 +2035,8 @@ The packet contains: > > Algorithm-Specific Fields for EdDSA keys: > > - - MPI of an integer representing the secret key, which is a > - scalar of the public EC point. > + - an opaque octet string k, in the notation of > + [](#I-D.irtf-cfrg-eddsa), Section 3.2 "Keys". Right. It's not a scalar of the public EC point. It is the one which generates the scalar. In my opinion, "MPI of an integer representing the secret key" is not wrong. -- From nobody Tue Feb 14 08:41:38 2017 Return-Path: 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 5EAB31293DC for ; Tue, 14 Feb 2017 08:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 UD2lEUCtMOQ9 for ; Tue, 14 Feb 2017 08:41:35 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 851C81296A4 for ; Tue, 14 Feb 2017 08:41:35 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 11so127174022qkl.3 for ; Tue, 14 Feb 2017 08:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eAFcVJgFi1X4X4ZN0sNGjyvtL0nFcJoqPElHJXIcvnw=; b=Blld8GEXmbJ2WIDd2mn7BdfnSb0pLvMz0kT9YG9FdDa03tBndYhdxh5M4vUzXWYWNw pyR/4ORbe0ZcMxj39AbqmpfLr5eUYATtcf2ZYxskjWAAXvMzNc8gWLC30//CTeb7Bxwz A0VfN+xkCNzYo7skeS0Yfm0vbqtzudCyXiyX0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=eAFcVJgFi1X4X4ZN0sNGjyvtL0nFcJoqPElHJXIcvnw=; b=p8YOTz0/lzW6KLA9KDR2BQsf7Wc2jyR1m3qHGdWYfBt+Fid/KvY0g3KpNy3fPJTgjv 5QccZpce7x9TEuM5409+X2D0QlYli2MczBF/hAL6SkeOKDC8kn52RH78S/Lg5QpP+PnR SUg/sV/xwSp8HE/idtZSUdID+kLcHRXpgOUfytv0IHJO6cIk9T5DBDXKHZhCtL/vG25v eEt6PDJV+EgqDwcSNOtR+ijcwH2i5m92FuVxRxHvczGwV+C58ZKiCiyM6idjx7Mh851M pU7URwG+GYHgpcvH5dt5jf4d9TuNZawYUtCnjvt1YmgNBs2JCsYfFON1CaRqne0GDfvO QOkg== X-Gm-Message-State: AMke39l03oxp47R09dQ72qZgQNdd+e5+q0SruFt4mJebFKJ7FzDdQJha8mhqff4K7EN/BU07252jiUmIwx5A2sLS X-Received: by 10.55.27.13 with SMTP id b13mr3153687qkb.246.1487090494235; Tue, 14 Feb 2017 08:41:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.94.244 with HTTP; Tue, 14 Feb 2017 08:41:13 -0800 (PST) In-Reply-To: <87shnhxhah.fsf_-_@wheatstone.g10code.de> References: <87shnhxhah.fsf_-_@wheatstone.g10code.de> From: Tom Ritter Date: Tue, 14 Feb 2017 10:41:13 -0600 Message-ID: To: IETF OpenPGP , "brian m. carlson" , Jon Callas Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:41:37 -0000 On 14 February 2017 at 03:17, Werner Koch wrote: > 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 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. This seems the same question/solution of some sort of authenticated chunked-streaming mode. I mentioned this a couple years ago but didn't get much discussion: https://www.ietf.org/mail-archive/web/openpgp/current/msg07546.html -tom From nobody Tue Feb 14 09:26:57 2017 Return-Path: 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 9D881129454 for ; Tue, 14 Feb 2017 09:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 9R_RCR2n9G_7 for ; Tue, 14 Feb 2017 09:26:53 -0800 (PST) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (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 BF75B12941A for ; Tue, 14 Feb 2017 09:26:53 -0800 (PST) Received: by jupiter.mumble.net (Postfix, from userid 1014) id E85CB60A7A; Tue, 14 Feb 2017 17:26:43 +0000 (UTC) From: Taylor R Campbell To: NIIBE Yutaka In-reply-to: <87y3x9yppw.fsf@fsij.org> (gniibe@fsij.org) Date: Tue, 14 Feb 2017 17:26:52 +0000 Sender: Taylor R Campbell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20170214172643.E85CB60A7A@jupiter.mumble.net> Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] patch for EdDSA key packet formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 17:26:55 -0000 > Date: Tue, 14 Feb 2017 20:30:19 +0900 > From: NIIBE Yutaka Hi, Niibe-san! Thanks for the review. > > @@ -1936,8 +1936,9 @@ A version 4 packet contains: > > - the octets representing a curve OID, defined in > > section NN{FIXME}; > > > > - - a MPI of an EC point representing a public key Q as described > > - under EdDSA Point Format below. > > + - a MPI, encoded as described under EdDSA Point Format, of an EC > > + point A, in the notation of [](#I-D.irtf-cfrg-eddsa), > > + Section 3.2 "Keys". > > I think that the expression "an EC point A" would not be good. In RFC > 8032, Section 3.1 "Encoding" explains about ENC(), the little-endian > encoding, and Section 3.2 "Keys" says: > > The EdDSA public key is ENC(A). > > ... where A is an EC point. > > We put the prefix 0x40 to ENC(A), it is not entirely same of > the notation of Section 3.2 "Keys". Right, but in RFC 8032, the letter `A' does mean a point on the curve. What my text says is that we encode the point A using the encoding described below in the Section 13.3 `EdDSA Point Format'. This is not the same as storing the RFC 8032 public key, which is the point A encoded as ENC(A). It may be that the Section 13.3 `EdDSA Point Format' encoding is actually 0x40 || ENC(A), but I'm not sure offhand. > > @@ -2034,8 +2035,8 @@ The packet contains: > > > > Algorithm-Specific Fields for EdDSA keys: > > > > - - MPI of an integer representing the secret key, which is a > > - scalar of the public EC point. > > + - an opaque octet string k, in the notation of > > + [](#I-D.irtf-cfrg-eddsa), Section 3.2 "Keys". > > Right. It's not a scalar of the public EC point. It is the one > which generates the scalar. > > In my opinion, "MPI of an integer representing the secret key" is not > wrong. You are probably right! I'm afraid I neglected to write notes when I prepared the patch, so I forgot where in the code I should have cited for that. Do you have a quick reference to the source code in libgcrypt or gnupg that handles encoding this? From nobody Tue Feb 14 12:17:34 2017 Return-Path: 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 EF33E1297F3 for ; Tue, 14 Feb 2017 12:17: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 69_8VZ4VVvJs for ; Tue, 14 Feb 2017 12:17:30 -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 BE58D1297F0 for ; Tue, 14 Feb 2017 12:17:30 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1cdjXU-0001C1-Lk for ; Tue, 14 Feb 2017 21:17:28 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1cdjUl-0004ji-2W for ; Tue, 14 Feb 2017 21:14:39 +0100 From: Werner Koch To: IETF OpenPGP References: <87shnhxhah.fsf_-_@wheatstone.g10code.de> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: IETF OpenPGP Date: Tue, 14 Feb 2017 21:14:33 +0100 In-Reply-To: (Tom Ritter's message of "Tue, 14 Feb 2017 10:41:13 -0600") Message-ID: <87lgt8wmvq.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Khaddafi_insurgency_Bin_Laden_Ermes_Freeh_Gazprom_AIMSX_AFSPC_kilo=c"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 20:17:33 -0000 --=Khaddafi_insurgency_Bin_Laden_Ermes_Freeh_Gazprom_AIMSX_AFSPC_kilo=c Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > chunked-streaming mode. I mentioned this a couple years ago but > didn't get much discussion: > https://www.ietf.org/mail-archive/web/openpgp/current/msg07546.html for easier reference, here is Tom's mail: Date: Tue, 24 Mar 2015 07:25:31 -0500 Adam's post on streaming API's has been posted before: =20=20 The same problem is the root cause of the Java GCM CipherInputStream issue: =20=20 But I haven't seen any discussion of Adam's point that one _can_ construct a format for chunking and authenticating the chunks (and ordering thereof) to provide authenticated streaming. And that someone has already done so: =20=20 I think support for a mode like this would be good to consider, and I think if IPR allows it, a fully-specified design for it is a good place to start. =20=20 -tom =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Khaddafi_insurgency_Bin_Laden_Ermes_Freeh_Gazprom_AIMSX_AFSPC_kilo=c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWKNlKQAKCRD/gK6dHew1 jd2PAQDl5QTrLueljMikZcX6QGQs+69x7k1mSVLZHg5NPT8NbQD/bmN7EtB95+ur 2sar+A0uj0Pc9nH6cRGuBtt0cQcWHAQ= =2Bx9 -----END PGP SIGNATURE----- --=Khaddafi_insurgency_Bin_Laden_Ermes_Freeh_Gazprom_AIMSX_AFSPC_kilo=c-- From nobody Tue Feb 14 19:20:41 2017 Return-Path: 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 B48DA1294AA for ; Tue, 14 Feb 2017 19:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org 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 rWls4uJecjzt for ; Tue, 14 Feb 2017 19:20:37 -0800 (PST) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (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 CC12B12945C for ; Tue, 14 Feb 2017 19:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=yE+H+HTn+iHL7H1liBu3muGCzLoqNBrDh8X7yLy3/SU=; b=cmNg6GRj3+XO+1l3wx5BVlN4tVEjBV+EdzhoDFoffBuPbIsFUT96Ao3bDsvCCX6J3x0jYXrztx5epgBfmfABDX4Vi8hFQgQlyyIV4jzGC8+3D+yVQx33+ggV05JuPxfpS5oeP1qNKgFVyn1CzwjyZBjepD9zv0teI8t49v2dxjzbjiPw2gscK/1g2fFVol3nKvAYn5n7SWudIv97Rchcy4p7ty6ZrF2alIevt2vdBcFPG/Pa+lD6RKfpI6Rp2IqtyG8awxRTaKUvQ5oULXabaEr046ZMGOG332Ak7fxu5Cpoxd6O80XmltV2YtbnZMokt+Q9MQaveuhEfjq3uDWC+Q==; Received: from 140.200.232.153.ap.dti.ne.jp ([153.232.200.140] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cdq8v-0005pj-A0; Wed, 15 Feb 2017 04:20:35 +0100 Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Wed, 15 Feb 2017 12:20:28 +0900 From: NIIBE Yutaka To: Taylor R Campbell In-Reply-To: <20170214172643.E85CB60A7A@jupiter.mumble.net> References: <20170214172643.E85CB60A7A@jupiter.mumble.net> Date: Wed, 15 Feb 2017 12:20:28 +0900 Message-ID: <87wpcsjg1v.fsf@iwagami.gniibe.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] patch for EdDSA key packet formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:20:40 -0000 Taylor R Campbell wrote: > Right, but in RFC 8032, the letter `A' does mean a point on the curve. Yes. > What my text says is that we encode the point A using the encoding > described below in the Section 13.3 `EdDSA Point Format'. This is not > the same as storing the RFC 8032 public key, which is the point A > encoded as ENC(A). > > It may be that the Section 13.3 `EdDSA Point Format' encoding is > actually 0x40 || ENC(A), but I'm not sure offhand. I believe this (0x40 || ENC(A)) is the `EdDSA Point Format' encoding. > You are probably right! I'm afraid I neglected to write notes when I > prepared the patch, so I forgot where in the code I should have cited > for that. Do you have a quick reference to the source code in > libgcrypt or gnupg that handles encoding this? In GnuPG, secret keys are primarily handled by gpg-agent with libgcrypt. And libgcrypt stores them in the format of SEXP [0]. So, GnuPG only handles OpenPGP secret keys when importing/exporting in OpenPGP format. For importing, we have the function parse_key in gnupg/g10/parse-packet.c:2112 (in the release 2.1.18). When secret key is not protected, it is handled by the mpi_read function (at line 2526). Here, in the code, the expression is "pk->pkey[i]", where pk and pkey stand for "public key", but this is because of historical reason, it means secret key materials. And then, it is handled by the function transfer_secret_keys in gnupg/g10/import.c:1788. It composes SEXP around line 1917, by "%m" format, which means MPI, to send gpg-agent. Exporting is similar. In the function do_key in gnupg/g10/build-packet.c:354, non-protected secret key is written by gpg_mpi_write at line 478. So, for the GnuPG implementation, secret key is handled as MPI. But I think that this is basically due to its historical reason, when keys in OpenPGP format were specified as MPI. For specification, "an opaque octet string k" may be better. I support this, personally. On the other hand, I don't know why the ECC format of 04 || x || y was described as MPI in RFC6637. For me, it is an octet string composed by two MPIs and the prefix. [0] SEXP --- (S-expressions) http://people.csail.mit.edu/rivest/sexp.html -- From nobody Tue Feb 14 19:35:01 2017 Return-Path: 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 78ED81293E1 for ; Tue, 14 Feb 2017 19:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Dy5YH9NAL4ji for ; Tue, 14 Feb 2017 19:34:57 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055C0129436 for ; Tue, 14 Feb 2017 19:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1487129696; x=1518665696; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ti3l8usVD8N+xo+0vrrbmbgw2tW6BN+fCa8+Hs1f4P0=; b=vIaqacY7dIKl4qR4F01GZ0J2NTT/aBnsOkT8Ijv1hLZvdS4bZVhdOwRI 8DEI445I0T+Pu82+P7/bywHzcWhAfIMTnOPZvkMQ9Oaa2q/Pv8dMpzOvV aYOu/JUsQrBSc0ghdZm/XisPa/GhUcrnujQ4Y2+1utl1x6vygiDo2SVmj RzTmAn+bhkgBiJkaKNP9IgqCYBDN0ygxLXgCRld/Z/84HDQj9SlhwU5cN 9hmCXnQoFf8rZzqEkRfmaLU8wVV/CfxVB3Cv6+DUzYMOlQOzjHbLs25Ni IcmidABfr80Y2V3FeIJa8SsNiV562d1e+k5E711LdCH51hVghM7Zyjw2C A==; X-IronPort-AV: E=Sophos;i="5.35,164,1483959600"; d="scan'208";a="135227464" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-c.UoA.auckland.ac.nz) ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Feb 2017 16:34:55 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Feb 2017 16:34:55 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Wed, 15 Feb 2017 16:34:55 +1300 From: Peter Gutmann To: Jon Callas , "brian m. carlson" Thread-Topic: [openpgp] Pull request for AEAD encrypted data packet with GCM Thread-Index: AQHShZWCI87Yb3MUEEORMG27g756BKFm2PqAgAKRNDc= Date: Wed, 15 Feb 2017 03:34:55 +0000 Message-ID: <1487129690833.78775@cs.auckland.ac.nz> References: <20170213010658.xmzo7yfgki2hqw42@genre.crustytoothpaste.net>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:34:59 -0000 Jon Callas writes:=0A= =0A= >I'll request that another mode than GCM be used. In particular, I disagree= =0A= >with it being "uncontroversial." It's the most controversial mode you coul= d=0A= >pick.=0A= =0A= +1. However the adjective I'd use for GCM is most trendy, not necessarily= =0A= most controversial. It's the mode you use without thinking about it=0A= because... um, because everyone says its cool. Like MongoDB, or Go, or=0A= Angular.js, or Bimodal IT.=0A= =0A= >GCM is very brittle. It breaks in very bad ways if you aren't careful with= =0A= >nonces/tags. There are many cases of people misusing it and getting worse= =0A= >than no security. I state that because if you *think* you're getting=0A= >authenticated data, but it's actually been altered in transit, and that wi= ll=0A= >likely cause issues in the receiving state machine.=0A= =0A= +1 again. You can take something like AES-CBC + HMAC and abuse it as much = as=0A= you want, e.g. by memsetting the IV to all zeroes on each block, and at mos= t=0A= you degrade to ECB, with no effect on the MAC's security. OTOH do that wit= h a=0A= single IV in GCM (=3D=3D CTR) mode (so you get a repeated IV) and you get a= =0A= catastrophic loss of security. CTR is RC4 all over again.=0A= =0A= >Furthermore, the multiply in GHASH is slow in software. =0A= =0A= Again, and at the risk of sounding like the Callas fan club... =0A= =0A= GCM is a dangerously easy to misuse encryption mode paired with a slow, als= o=0A= failure-prone MAC. If you want a minimal-fuss AEAD mode, just turn the=0A= current encryption into encrypt-then-MAC. It's a very minimal change, appe= nd=0A= an HMAC to the end of the existing encrypted data.=0A= =0A= >I think that GCM is actually controversial and dangerous for generic use.= =0A= =0A= Not sure about controversial since it's so trendy that most people don't th= ink=0A= about it but just use it, but it's certainly too dangerous for general use.= =0A= =0A= Peter.= From nobody Fri Feb 17 08:13:27 2017 Return-Path: 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 BCD3C129ACB for ; Fri, 17 Feb 2017 08:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 aFl_lMjrD-4u for ; Fri, 17 Feb 2017 08:13:24 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805E5129ACD for ; Fri, 17 Feb 2017 08:13:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 62055E2043; Fri, 17 Feb 2017 11:13:23 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02481-01; Fri, 17 Feb 2017 11:13:21 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7C02FE2042; Fri, 17 Feb 2017 11:13:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1487348001; bh=rIE3FHi+aQxdjyybtLattwNq0u20LHBqksqfx1rEuY8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=NnsnJCmzwpOqDwEukT7TVlym7ljJmm+TLLrey98jVOXdkGh4VuMksXkRiZ6sw9Rn6 Nhoo6YSlohLSAiTaRD1+CxmEQOFUMHT94ZrfV6m3WyFpGYGu8qRLVGQdAOgGxHfN8v ++QDkVleP1nYARUuH7UEwkCTPujT1CENUrcUmrgY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id v1HGDK2f008124; Fri, 17 Feb 2017 11:13:20 -0500 From: Derek Atkins To: "brian m. carlson" References: <20170213005928.2ytmjp3h2njyjcgy@genre.crustytoothpaste.net> <871sv1yy2k.fsf@wheatstone.g10code.de> Date: Fri, 17 Feb 2017 11:13:20 -0500 In-Reply-To: <871sv1yy2k.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 14 Feb 2017 09:29:55 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Pull request for 8-octet lengths X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:13:26 -0000 Werner Koch writes: > Hi Brian, > > thanks for posting the text. > > On Mon, 13 Feb 2017 01:59, sandals@crustytoothpaste.net said: >> There was some question as to whether we should use four-octet or >> eight-octet lengths for signatures (or some other technique), as one >> might want to sign more the 2^32 bytes of data. I've submitted a pull >> request[0] to use eight-octet lengths for all signatures. > > Although 64 bit numbers are often not easy to handle on small systems it > will be easy for such implementations to hash the required extra bytes > (thanks to Big Endian). > > This is an easy and straightforward change. Unless someone objects, I > will add this to the next draft. As long as we don't deprecate V4 Signatures I'm fine with this change. > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Feb 17 08:19:26 2017 Return-Path: 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 92D01127071 for ; Fri, 17 Feb 2017 08:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 TCjlvCIOKWri for ; Fri, 17 Feb 2017 08:19:24 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5680E129607 for ; Fri, 17 Feb 2017 08:19:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 65A0FE2044; Fri, 17 Feb 2017 11:19:23 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02481-02; Fri, 17 Feb 2017 11:19:22 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 32FE4E2043; Fri, 17 Feb 2017 11:19:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1487348362; bh=t/uCzgcuRSLB+z4aamMo0HAIGmnXgbNOG8ADPV27oK0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ss2mV2gimwU/szO/tSUWU9M1wAbnQRjcd1aP+bACfP2isB41XfI1LKX04ZJj256to wzxV6rzMx03lJl3+7b2WI9Xw6FBo0GuCPjwMB42pg6AmLdusMbysxX1GPxsZTwPHMS D7pGIDKVjedVT5HxlfhumeFwgHlb26UkIxFLQ8kA= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id v1HGJLqJ008521; Fri, 17 Feb 2017 11:19:21 -0500 From: Derek Atkins To: openpgp@ietf.org References: <87shnhxhah.fsf_-_@wheatstone.g10code.de> Date: Fri, 17 Feb 2017 11:19:21 -0500 In-Reply-To: <87shnhxhah.fsf_-_@wheatstone.g10code.de> (Werner Koch's message of "Tue, 14 Feb 2017 10:17:42 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jon Callas , "brian m. carlson" Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:19:25 -0000 +1 for your suggestions, Werner. -derek Werner Koch writes: > 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 -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Feb 23 11:10:04 2017 Return-Path: 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 58C0E129BED for ; Thu, 23 Feb 2017 11:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 ENwqk13l_0th for ; Thu, 23 Feb 2017 11:10:01 -0800 (PST) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (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 88AB8129A7F for ; Thu, 23 Feb 2017 11:10:01 -0800 (PST) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id C6F32402D9 for ; Thu, 23 Feb 2017 19:10:00 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=cP/KxD7d6t0RIex2Q52ZcBhViVsR2G6kP/9LvjSXEe4=; b=impevbVGZ1N5ixX2OVZutOF/R6Dxatq+DxxA9aoTKMxA+8xMyhFQfpVhvUM51iRT21ukOIMyb6ND5bYcxJt5+CVdt0rzW115QJV/2tLyngR4bnxTH3peqR6kscPVTxDz9IEhnkBu7+s9TnDbA94gfJYrpT3PcoXMphspbUmPTGDfbuGkm/RNlHrqe3MfOhVagm6tSaFs4yHA5RCgev3a+M1Px0ZsSZW6O4fqbHW1tA8YeVTnz4bCYsatLwtEZERW524wjfGbEbyVYoTgArte/ghzMZ6XFpEQt0S7v018afzK4JYFce3gneK8TSh0wk/M7c1vPXAlWzw8wVKr458ERA== Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Thu, 23 Feb 2017 19:10:00 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 2CD7FE0163; Thu, 23 Feb 2017 19:10:00 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 23 Feb 2017 14:09:59 -0500 To: gnupg-users@gnupg.org, "openpgp" From: vedaal@nym.hush.com In-Reply-To: Content-Type: multipart/alternative; boundary="=_13531d97fd2a241ddb02b5af3e7b79a9" Message-Id: <20170223191000.2CD7FE0163@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] SHA1 collision found X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:10:03 -0000 --=_13531d97fd2a241ddb02b5af3e7b79a9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 2/23/2017 at 1:27 PM, sivmu@web.de wrote:Today was announced that SHA1 is now completely broken https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html A few weeks back it was mentioned that there is a new proposal for a openpgp standart including a new algorithm for pgp fingerprints. As this is currently not applicable in practice, I would like to know what this new development means for pgp-gnupg and the use of SHA1 for key identification. After researching how the fingerprint is generated, I think it would be easy to include a new option in gnupg to print a fingerprint using sha256. Would that be something that will/can be included in future versions of gnupg ===== The Openpgp standards group is working on this. The link you give for the collision used 2 PDF's. Using a PDF is sort-of 'cheating', and does not extrapolate to being 'completely broken'. Assuming that it is possible to find a pre-image collision, i.e: [1] m1.txt 1 has an SHA1 hash of H1 [2] m2.txt will now have the same SHA1 hash H1 What will happen to in order to generate m2.txt is that there will be many trials of a gibberrish string added to the plaintext of m2.txt until one is found that has the same SHA1 hash as m1.txt BUT This will be quite visible in the plaintext of m2.txt, and won't fool anyone. With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the actual PDF the receiver reads, only in the meta-data, the appended PDF 'Suffix'. While this is *do-able* and a good reason to move on to a future SHA256 hash, it would not be transferable (at this time, based on the PDF collision data), to find a fingerprint collision for any v4 key. vedaal --=_13531d97fd2a241ddb02b5af3e7b79a9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On 2/23/2017 a= t 1:27 PM, sivmu@web.de wrote:
Today was announced that SHA1 is no= w completely broken
https://security.googleblog.com/2017/0= 2/announcing-first-sha1-collision.html

A few weeks back it was m= entioned that there is a new proposal for a openpgp standart including a ne= w algorithm for pgp fingerprints.
As this is currently not applicable in= practice, I would like to know what this new development means for pgp-gnu= pg and the use of SHA1 for key identification.

After researching how= the fingerprint is generated, I think it would be easy to include a new op= tion in gnupg to print a fingerprint using sha256. Would that be something = that will/can be included in future versions of gnupg

=3D=3D=3D=3D= =3D

The Openpgp standards group is working on this.

The link = you give for the collision used 2 PDF's.
Using a PDF is sort-of 'cheatin= g', and does not extrapolate to being 'completely broken'.

Assuming = that it is possible to find a pre-image collision, i.e:

[1] m1.txt 1= has an SHA1 hash of H1
[2] m2.txt will now have the same SHA1 hash H1
What will happen to in order to generate m2.txt  is that there w= ill be many trials of a gibberrish string added to the plaintext of m2.txt = until one is found that has the same SHA1 hash as m1.txt
BUT
This wil= l be quite visible in the plaintext of m2.txt, and won't fool anyone.
With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the ac= tual PDF the receiver reads, only in the meta-data, the appended PDF 'Suffi= x'.

While this is *do-able* and a good reason to move on to a future= SHA256 hash, it would not be transferable (at this time, based on the PDF = collision data), to find a fingerprint collision for any v4 key.

vedaal
 --=_13531d97fd2a241ddb02b5af3e7b79a9-- From nobody Fri Feb 24 07:15:26 2017 Return-Path: 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 EEE6C129881 for ; Fri, 24 Feb 2017 07:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.ai 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 sDDwLoZeVKkU for ; Fri, 24 Feb 2017 07:15:24 -0800 (PST) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (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 A4F97129868 for ; Fri, 24 Feb 2017 07:15:24 -0800 (PST) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 17285E03DE for ; Fri, 24 Feb 2017 15:15:24 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=l3Hz+TrY13tRvR3CZC7HTdvUTcmebYmlB+sGLFChHvQ=; b=x/yp/lZlgiv6NSMtkTQUBVsWkrEQil6QjzF4ngH48XU3j+4IN9O/lQQ2DD9fa9Qu2rulvolwB9zIovosTZvcLK3ZweaQs2xC0A9hqkBPImz1Muh2Wq7RbZPf3ta0j9TigioRN357kRlOaM8LX3OBvtA2OUOZqHxI6OWkTZEeoFoBJU5oQIgTtfutIe8V0LH4rZuhK18D9sLvzagCUNP9u9A1stSaZpk34eVfg+jo+RSAjxGnDSxGL1G8GRdTvjFaibIPA71gVFyuRMzC7RLosODLoPXxtBvMpe9rvbbuWd57qBkT40QxQXO6bBPu7/Kb5ZLzodj0AytySSBROMEkCw== Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Fri, 24 Feb 2017 15:15:23 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B27CFE05F7; Fri, 24 Feb 2017 15:15:23 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 24 Feb 2017 10:15:23 -0500 To: sivmu@web.de, gnupg-users@gnupg.org, "openpgp" From: vedaal@nym.hush.com In-Reply-To: Content-Type: multipart/alternative; boundary="=_016d63778d44bb08846937bb6da9b221" Message-Id: <20170224151523.B27CFE05F7@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] SHA1 collision found X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:15:26 -0000 --=_016d63778d44bb08846937bb6da9b221 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 2/23/2017 at 4:52 PM, sivmu@web.de wrote:... Not sure about you but I am not able to see the difference between a valid pgp key and "gibberish" ;) ... ===== In the example of the 2 pdf's, they started with one pdf, made another pdf, then multiple (more than billions) trials of adding a string to the second pdf so that it hashes to the first. With regard to generating a new key that hashes to a known specific key, the forger must do 2 things simultaneously; [1] generating new key material [2] seeing that the hashed fingerprint of the new key matches that of the first key The forger does not start with a newly generated key and add material so that the hash would match the first key (the case of the pdf's). If that were the case, then the key system would be broken now for the SHA1 hash. Even for v3 keys, which were not SHA1 hashed, the only way to generate a new key with the same fingerprint, would be to allow the key size to vary (usually to a bizarre key size that would be quite suspect, and not believed). Now, for a V4 key with an SHA1 hash, and a further restriction that the forged key size be the same as the first key, this is not known to be doable day, even with the google cloud computer sharing efforts, and the breakthrough of finding pdf's with the same hash. Again, I fully support moving to a secure hash, but I do think that users have more than enough time until the open-pgp group issues the official standard. vedaal --=_016d63778d44bb08846937bb6da9b221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On 2/23/2017 a= t 4:52 PM, sivmu@web.de wrote:
...
Not sure about you but I am = not able to see the difference between a valid pgp key and "gibberish" ;)...

=3D=3D=3D=3D=3D

In the example of the 2 pdf's,  th= ey started with one pdf, made another pdf, then multiple (more than billion= s) trials of adding a string to the second pdf so that it hashes to the fir= st.

With regard to generating a new key that hashes to a known speci= fic key, the forger must do 2 things simultaneously;

[1] generating = new key material
[2] seeing that the hashed fingerprint of the new key m= atches that of the first key

The forger does not start with a newly = generated key and add material so that the hash would match the first key (= the case of the pdf's).
If that were the case, then the key system would= be broken now for the SHA1 hash.

Even for v3 keys, which were not S= HA1 hashed, the only way to generate a new key with the same fingerprint, w= ould be to allow the key size to vary (usually to a bizarre key size that w= ould be quite suspect, and not believed).

Now, for a V4 key with an = SHA1 hash, and a further restriction that the forged key size be the same a= s the first key, this is not known to be doable day, even with the google c= loud computer sharing efforts, and the breakthrough of finding pdf's with t= he same hash.

Again, I fully support moving to a secure hash, but I = do think that users have more than enough time until the open-pgp group iss= ues the official standard.


vedaal
 --=_016d63778d44bb08846937bb6da9b221--