From nobody Mon Aug 3 08:08:21 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309531A907A for ; Mon, 3 Aug 2015 08:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.311 X-Spam-Level: * X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 Ihbp2dUsMnXD for ; Mon, 3 Aug 2015 08:08:16 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648381A907E for ; Mon, 3 Aug 2015 08:08:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D6819E2035; Mon, 3 Aug 2015 11:08:12 -0400 (EDT) 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 06549-09; Mon, 3 Aug 2015 11:08:05 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 6D5AEE2034; Mon, 3 Aug 2015 11:08:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438614485; bh=nBCKDeyPDBzBGG/HZDgdH8u/udIZpZVjQkjlZAe2C2g=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=SVlsiPPvyOaX2YjV1PNDnS9Jouv9kOzENmQ4sQnNxqPZAeheSjdMHNDlYHxFnd6bw C2A/gKqZP2vr0alEwNSl/BZUyyzPCSgeHBflifORFnwQoRanNejfAkRk0bBe05CR+e F4Idy+IWLXYLfXxb+Hm0nYSMm5Ct37SvUopPAues= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t73F84cc018970; Mon, 3 Aug 2015 11:08:04 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> Date: Mon, 03 Aug 2015 11:08:04 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 31 Jul 2015 14:31:11 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Derek Atkins , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 15:08:20 -0000 Phillip Hallam-Baker writes: > On Fri, Jul 31, 2015 at 9:28 AM, Derek Atkins wrote: > > Daniel Kahn Gillmor writes: >=20=20=20=20 > >> At this point, any attempt to hold Mallet accountable is going to = have > to > >> rely on a human examining the logs and working out that Mallet mus= t have > >> generated the malicious pair of keys. There is going to be no way = to > unwind > >> the thing automatically. >=20=20=20=20 > Why?=C2=A0 M1 and M2 are completely different fingerprints, unless yo= u're > assuming that the x's are the same.=C2=A0 If the x's are the same tha= t means > that Mallet has performed a 2^50 level attack to get 100 bits to matc= h! > How long and how much energy does Mallet have to do this?=C2=A0 It's > certainly not something s/he is going to do over a long weekend! > > Not with RSA keys. With ECC keys, different matter entirely. Even if you could do 30,000,000 ECC key generations per second (I think my laptop can do about 3,000-10,000 -- I'm not sure how to measure that beyond running an openssl speed test), and also assuming the SHA hash to compute the fingerprint is "free", to do 2^50 keygen + sha computations would still take 37,529,996 seconds or 434 days, which is over a year! Remember, the fingerprint is over the public key, so you still have to actually perform the ECC g^x operation for each trial. So no, this is not something Mallet is going to be able to do over a weekend without expending a LOT of effort and cost. I guess if they had access to a few hundred really beefy machines (and the electricity to power them) they might be able to accomplish this feat. So sure, maybe a large corporation or gov't agency could perform this kind of Mallet attack, but generally not some teenager sitting in their basement. Maybe in a decade or two this will be feasible to a singleton. This of course is still based on your (rather forced) 100-bit truncated hash concept. If applications use the full 160-bit fingerprint (or more if we migrate up to a larger hash) then a 2^80 attack would still be out of reach. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Aug 3 09:59:16 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD71AC414 for ; Mon, 3 Aug 2015 09:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 TQLm8C5O7v6a for ; Mon, 3 Aug 2015 09:59:11 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 D1DCB1A03E3 for ; Mon, 3 Aug 2015 09:59:11 -0700 (PDT) Received: by ioeg141 with SMTP id g141so151146056ioe.3 for ; Mon, 03 Aug 2015 09:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iKMF0trxSK2NvdmaZCp/PcYriDXWQPwKcOs2RGuiG74=; b=uKCs92T7a0M0Bc2uI0QPG4QGqOrdrO9396h+7uP13UyETDVLSaICYiFWL8QpoOXhUh 2PlwTV1TfEiy18WUwPgmxDWSjRtFuC1z+Sj1LjXUOVR6R5/ZDzmqcwpLeyaMP/XGCd/9 O8wY8aFu9ThC0FVLMmlxuDn+eWTcpdYFACgJAwUN6UVV2rZotUndhFKJBFojcS1OVx0q lnkdNXXm6nsh9prlqex+WWEiLXlWkGyW/2R1308y6ZH86feLldfSECiIteAGiABTf4Nx n4u4IouErRBAG1yCdHcg+/Xxq/JkPztjiDK022PGk87t8zVBUqHx2MhURZazniA84Zyv mlrQ== MIME-Version: 1.0 X-Received: by 10.107.137.42 with SMTP id l42mr22065115iod.150.1438621151227; Mon, 03 Aug 2015 09:59:11 -0700 (PDT) Received: by 10.107.14.136 with HTTP; Mon, 3 Aug 2015 09:59:11 -0700 (PDT) In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> Date: Mon, 3 Aug 2015 16:59:11 +0000 Message-ID: From: Gregory Maxwell To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 16:59:13 -0000 On Mon, Aug 3, 2015 at 3:08 PM, Derek Atkins wrote: > Remember, the fingerprint is over the public key, so you still have to > actually perform the ECC g^x operation for each trial. Take care to not confuse what you would do with what an attacker _must_ do. For each new key to generate the attacker can perform only a single addition of G or a doubling (whichever is faster for the curve in question), then a conversion to affine (which is nearly free-- marginally, ~one field multiply-- if done in a batch). E.g. You compute, P_0 = xG P_1 = P_0 + G (x_1 = x_0 + 1) P_2 = P_1 + G (x_2 = x_1 + 1) ... There are even faster techniques available for some curves. If software for this doesn't run in the rough ballpark of a million per second on a current gen laptop/desktop or 10 million/sec on a GPU even on a fairly generic curve, it's probably completely naieve. From nobody Mon Aug 3 10:20:14 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3EA1B2AA2 for ; Mon, 3 Aug 2015 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.72 X-Spam-Level: X-Spam-Status: No, score=0.72 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, HELO_MISMATCH_ORG=0.611, T_DKIM_INVALID=0.01] autolearn=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 rO5e8_g0ik_O for ; Mon, 3 Aug 2015 10:20:12 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E971ACEFD for ; Mon, 3 Aug 2015 10:20:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B27AEE2034; Mon, 3 Aug 2015 13:20:10 -0400 (EDT) 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 07682-07; Mon, 3 Aug 2015 13:20:08 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id C0055E2035; Mon, 3 Aug 2015 13:20:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438622408; bh=s9oD53boGUOiSrP6D3c7HO85L0YROUdt6qB2Ts/qHvU=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Qcc89Y4BlpKePI8hYS/ADsrJ4SuU4xhQc+P2TnfO8J9PTFN7fFeLv1iCXMezxMsDu 5ZFp6z1Wbz7sqSHsOc4sppWBIRn/y9vRo9E9YimpciNSFV24/FMRuszdVqHnPbQ4If QYhW8Uek5Y9bd4HMxeIsGX/e298E39VSPiPUbymA= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 3 Aug 2015 13:20:08 -0400 Message-ID: <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> Date: Mon, 3 Aug 2015 13:20:08 -0400 From: "Derek Atkins" To: "Gregory Maxwell" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Phillip Hallam-Baker , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:20:13 -0000 On Mon, August 3, 2015 12:59 pm, Gregory Maxwell wrote: > On Mon, Aug 3, 2015 at 3:08 PM, Derek Atkins wrote: >> Remember, the fingerprint is over the public key, so you still have to >> actually perform the ECC g^x operation for each trial. > > Take care to not confuse what you would do with what an attacker _must_ > do. > > For each new key to generate the attacker can perform only a single > addition of G or a doubling (whichever is faster for the curve in > question), then a conversion to affine (which is nearly free-- > marginally, ~one field multiply-- if done in a batch). > > E.g. You compute, > P_0 = xG > P_1 = P_0 + G (x_1 = x_0 + 1) > P_2 = P_1 + G (x_2 = x_1 + 1) > ... > > There are even faster techniques available for some curves. > > If software for this doesn't run in the rough ballpark of a million > per second on a current gen laptop/desktop or 10 million/sec on a GPU > even on a fairly generic curve, it's probably completely naieve. Luckily my computations (which you unfortunately cut out) were based on 30 million attempts per second, so my results (the attack taking over a year) is still correct! Indeed, your numbers are still 3x slower than my computation estimates. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Aug 3 10:32:45 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA41B2D30 for ; Mon, 3 Aug 2015 10:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 M9pT5vyNQNaV for ; Mon, 3 Aug 2015 10:32:34 -0700 (PDT) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id 25F471B2D2A for ; Mon, 3 Aug 2015 10:32:34 -0700 (PDT) Received: from straylight.m.ringlet.net (unknown [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id 5AAA010E6 for ; Mon, 3 Aug 2015 20:32:32 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 254035f by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Mon, 03 Aug 2015 20:32:31 +0300 Date: Mon, 3 Aug 2015 20:32:31 +0300 From: Peter Pentchev To: Derek Atkins Message-ID: <20150803173231.GG3067@straylight.m.ringlet.net> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m1UC1K4AOz1Ywdkx" Content-Disposition: inline In-Reply-To: <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Gregory Maxwell , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:32:40 -0000 --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 03, 2015 at 01:20:08PM -0400, Derek Atkins wrote: >=20 > On Mon, August 3, 2015 12:59 pm, Gregory Maxwell wrote: > > On Mon, Aug 3, 2015 at 3:08 PM, Derek Atkins wrote: > >> Remember, the fingerprint is over the public key, so you still have to > >> actually perform the ECC g^x operation for each trial. > > > > Take care to not confuse what you would do with what an attacker _must_ > > do. > > > > For each new key to generate the attacker can perform only a single > > addition of G or a doubling (whichever is faster for the curve in > > question), then a conversion to affine (which is nearly free-- > > marginally, ~one field multiply-- if done in a batch). > > > > E.g. You compute, > > P_0 =3D xG > > P_1 =3D P_0 + G (x_1 =3D x_0 + 1) > > P_2 =3D P_1 + G (x_2 =3D x_1 + 1) > > ... > > > > There are even faster techniques available for some curves. > > > > If software for this doesn't run in the rough ballpark of a million > > per second on a current gen laptop/desktop or 10 million/sec on a GPU > > even on a fairly generic curve, it's probably completely naieve. >=20 > Luckily my computations (which you unfortunately cut out) were based on 30 > million attempts per second, so my results (the attack taking over a year) > is still correct! Indeed, your numbers are still 3x slower than my > computation estimates. Um, I believe that the point is that Mallory doesn't *need* to brute-force anything to create two keys with almost-identical hashes. ICBW, but I think that the idea is that Mallory, in the process of creating the first key, is in possession of some intermediate information that enables him to create a related key much cheaper, with a single run. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --m1UC1K4AOz1Ywdkx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVv6WrAAoJEGUe77AlJ98TG04QALgLmlsPJ4Mr1r9Z2T3mFzcx YLLyuIfBE9p/UWSTYUYTgf5DHaxdkY8sOMYbA8qeT2lrTP8+mhJGqTX8G6FiygXP bAGA/ACu3pDKc4VN5yVVADGjW3rOvR2IZwc7Ax3J0Rjn2yp84ZldaYR1N9lehJ8o ve2f98jvXdqdN5iiVDlSYIiVywYq56CKLKOOyBEg46YSlCAgWTXA3tIqae5//S4e uEK/K+Bb9+F7DMCwCWZHj+fNLBm9flem/GF5pHDL+DrIEIDHCYqkNV6Skpwb/NzC L032AxEHcMHIs+MOrvzraEAYtak7pzP5gX/YCid9oZE5niqz5enKQ8fWi9hnjXM1 3mf6W6xvs7ewUE/ymx1/uoQ/XmYjRVD4X8wnUl3t1ZH5XepRzwLOWtFKZ6DzXDd0 hCcNUDsIlqs1K7WymUVrmxs4qOl/mbAsKic4NRQE2kLDnKRpmc4qPPfOly0RI5RW Exg4TnzjGWfC2mWTOU4dyMtNaBSoxC0CiV1Kk1TkZjoCcRR0cfZACpBl68OMJSTO g/0ShhV1Do0e3lHeE0DqJ5DCphqg25ChJIY+P72Bdx6Qy6PlmxvTzM9PYu1m00aK 4MelNsMUr4sj7YXRzRRJX8KxzeVry18Bsb0ZtFlSKhIpw0ul9yGTwtbQgFbcwI1X fBXfHQvskMSS69UtAJ5F =BXQc -----END PGP SIGNATURE----- --m1UC1K4AOz1Ywdkx-- From nobody Mon Aug 3 10:47:44 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DDF1B2D6C for ; Mon, 3 Aug 2015 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 HQCIryVwt_gm for ; Mon, 3 Aug 2015 10:47:41 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F61C1B2D6B for ; Mon, 3 Aug 2015 10:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DE29BE2034; Mon, 3 Aug 2015 13:47:39 -0400 (EDT) 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 08299-04; Mon, 3 Aug 2015 13:47:37 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id B9CEEE2035; Mon, 3 Aug 2015 13:47:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438624057; bh=0tFs2beDZDLJl4PNabRF0b0ZF+Rg/KrtvzQwmNbJx4I=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=dRG5e7fJruEgB41N3PhX5W+rjcVGcfeWcBFk4MOCW8kYGrmbi1ANz2kILxoOeXNPh ZOVMud/WgJU7vErTQ58BtGEoLkIqPGhXrHBOdBxDuabeBMJwiuxstbsJ5EBz5ZHXOD oUQ4Kqouazu5BpHyWvleyos+gn0VLxqIjqKaW68M= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 3 Aug 2015 13:47:37 -0400 Message-ID: <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> In-Reply-To: <20150803173231.GG3067@straylight.m.ringlet.net> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> Date: Mon, 3 Aug 2015 13:47:37 -0400 From: "Derek Atkins" To: "Peter Pentchev" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Gregory Maxwell , Phillip Hallam-Baker , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:47:42 -0000 On Mon, August 3, 2015 1:32 pm, Peter Pentchev wrote: >> Luckily my computations (which you unfortunately cut out) were based on >> 30 >> million attempts per second, so my results (the attack taking over a >> year) >> is still correct! Indeed, your numbers are still 3x slower than my >> computation estimates. > > Um, I believe that the point is that Mallory doesn't *need* to brute-force > anything to create two keys with almost-identical hashes. ICBW, but I > think > that the idea is that Mallory, in the process of creating the first key, > is in possession of some intermediate information that enables him to > create > a related key much cheaper, with a single run. They do still need to brute-force -- they still need to find a hash collision. Whether they do this randomly or forcing it still requires on the order of 2^50 operations (assuming they want to match 100 bits of a hash). My previous statements assumed the hashing was free, but we all know that's not true. On my laptop I can perform on the order of 3 to 5 million SHA operations per second (3.4 SHA256, and 4.6 SHA1) on 16 bytes of data. So we're still well within the 30 million trials per second. But how about this, I'll be nice and give you yet another order of magnitude to 300 million attempts per second. That STILL limits you to ~46 days to find a 100-bit collision. But the data being hashed is more than 16 bytes so I still think it's going to be closer to 30 vs 300 million attempts per second. Thanks, > > G'luck, > Peter -derek > -- > Peter Pentchev roam@ringlet.net roam@FreeBSD.org pp@storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Aug 3 13:22:20 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9AC1B30F1 for ; Mon, 3 Aug 2015 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 qcIqMztX7k9l for ; Mon, 3 Aug 2015 13:22:17 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 DE9A31B30EA for ; Mon, 3 Aug 2015 13:22:16 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so83914026lbb.0 for ; Mon, 03 Aug 2015 13:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yjQDWkBtXJgg0JvT9caHF562yzGA8QjkZtZxq+y1reI=; b=B+xPRNsfuZAeHZHtaLEKZhGy/2w6b/cDkxIezzWFiVD/ReuM4EeFBnIyiFxL4teRTn w9hWoK+erpBTYE0caagZ9EfBHZ1+o92AW/PCPdqi62SyRpvRBArjD+ZElRNS/V0ExybZ 88EZbxBplGZvKGL+dXw1E5ZIckMeUzSFKiSBwf3Uhpb1tqokb2QIVBKLZVlMVLwUdE3o 4AF7aL/+eixyZUO2CCkW2mszLv0a23EHfpmiwrwByTUP5eJCfNVamrGdZHSwNcnOJCgn sjKQi9EgDLL2Yej3TfpYJRcn1SomGhnaY1s2B023+7N57M6pywmUzgLpa1MlHxNy7ggg o+xg== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr18875975lbc.79.1438633335353; Mon, 03 Aug 2015 13:22:15 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 3 Aug 2015 13:22:15 -0700 (PDT) In-Reply-To: <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> Date: Mon, 3 Aug 2015 16:22:15 -0400 X-Google-Sender-Auth: 0ULiRz3Uln1-5DSW1XrTz48sjD4 Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c3ca22ea78eb051c6dec54 Archived-At: Cc: Gregory Maxwell , IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 20:22:18 -0000 --001a11c3ca22ea78eb051c6dec54 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 3, 2015 at 1:20 PM, Derek Atkins wrote: > > On Mon, August 3, 2015 12:59 pm, Gregory Maxwell wrote: > > On Mon, Aug 3, 2015 at 3:08 PM, Derek Atkins wrote: > >> Remember, the fingerprint is over the public key, so you still have to > >> actually perform the ECC g^x operation for each trial. > > > > Take care to not confuse what you would do with what an attacker _must_ > > do. > > > > For each new key to generate the attacker can perform only a single > > addition of G or a doubling (whichever is faster for the curve in > > question), then a conversion to affine (which is nearly free-- > > marginally, ~one field multiply-- if done in a batch). > > > > E.g. You compute, > > P_0 = xG > > P_1 = P_0 + G (x_1 = x_0 + 1) > > P_2 = P_1 + G (x_2 = x_1 + 1) > > ... > > > > There are even faster techniques available for some curves. > > > > If software for this doesn't run in the rough ballpark of a million > > per second on a current gen laptop/desktop or 10 million/sec on a GPU > > even on a fairly generic curve, it's probably completely naieve. > > Luckily my computations (which you unfortunately cut out) were based on 30 > million attempts per second, so my results (the attack taking over a year) > is still correct! Indeed, your numbers are still 3x slower than my > computation estimates. Your original assertion was broken. I don't think it very likely that someone is going to spend more than a machine year to generate a vanity key unless they can get someone else to pay for the time. A hundred machine years for creating a key collision attack is completely viable. Also when we are talking about PGP Key fingerprint, the fingerprint is over the key binding and not just the key and so it is malleable. I can well imagine someone making use of all that Bitcoin hardware for some mischief. Hence a reason to go for SHA-2-512. Again, this is only a security consideration that has to be noted. --001a11c3ca22ea78eb051c6dec54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 1:20 PM, Derek Atkins <derek@ihtfp.com> wrote:

On Mon, August 3, 2015 12:59 pm, Gregory Maxwell wrote:
> On Mon, Aug 3, 2015 at 3:08 PM, Derek Atkins <derek@ihtfp.com> wrote:
>> Remember, the fingerprint is over the public key, so you still hav= e to
>> actually perform the ECC g^x operation for each trial.
>
> Take care to not confuse what you would do with what an attacker _must= _
> do.
>
> For each new key to generate the attacker can perform only a single > addition of G or a doubling (whichever is faster for the curve in
> question), then a conversion to affine (which is nearly free--
> marginally, ~one field multiply-- if done in a batch).
>
> E.g. You compute,
> P_0 =3D xG
> P_1 =3D P_0 + G=C2=A0 (x_1 =3D x_0 + 1)
> P_2 =3D P_1 + G=C2=A0 (x_2 =3D x_1 + 1)
> ...
>
> There are even faster techniques available for some curves.
>
> If software for this doesn't run in the rough ballpark of a millio= n
> per second on a current gen laptop/desktop or 10 million/sec on a GPU<= br> > even on a fairly generic curve, it's probably completely naieve.
Luckily my computations (which you unfortunately cut out) were = based on 30
million attempts per second, so my results (the attack taking over a year)<= br> is still correct!=C2=A0 Indeed, your numbers are still 3x slower than my computation estimates.

Your original assert= ion was broken. I don't think it very likely that someone is going to s= pend more than a machine year to generate a vanity key unless they can get = someone else to pay for the time.

A hundred machin= e years for creating a key collision attack is completely viable.

Also when we are talking about PGP Key fingerprint, the fin= gerprint is over the key binding and not just the key and so it is malleabl= e.=C2=A0

I can well imagine someone making use of = all that Bitcoin hardware for some mischief. Hence a reason to go for SHA-2= -512.


Again, this is only a securit= y consideration that has to be noted.
=C2=A0
--001a11c3ca22ea78eb051c6dec54-- From nobody Mon Aug 3 17:39:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76B11B31B0 for ; Mon, 3 Aug 2015 17:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 b7DRMYdPZGLm for ; Mon, 3 Aug 2015 17:38:58 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE98D1B31A9 for ; Mon, 3 Aug 2015 17:38:57 -0700 (PDT) Received: from localhost (p57B2CB30.dip0.t-ipconnect.de [87.178.203.48]) by mail.mugenguild.com (Postfix) with ESMTPSA id D39C25FCEF; Tue, 4 Aug 2015 02:34:54 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> From: Vincent Breitmoser To: Derek Atkins In-reply-to: <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> Date: Tue, 04 Aug 2015 02:38:50 +0200 Message-ID: <87io8v7uqt.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Gregory Maxwell , Phillip Hallam-Baker , Peter Pentchev , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:38:59 -0000 Maybe I missed an answer to this, but could someone please explain what the point of finding a collision on a pgp fingerprint is, and why we need to consider it as an attack scenario in the first plce? Let's say you spent the (cpu) time, and you now have two different pgp keys with the same fingerprint. What do you do with those? - V From nobody Mon Aug 3 19:43:09 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95B61B33A3 for ; Mon, 3 Aug 2015 19:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 sAN6S7L8qsW1 for ; Mon, 3 Aug 2015 19:43:06 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE891B33A2 for ; Mon, 3 Aug 2015 19:43:05 -0700 (PDT) Received: from localhost (p57B2CB30.dip0.t-ipconnect.de [87.178.203.48]) by mail.mugenguild.com (Postfix) with ESMTPSA id E785F5FCEF for ; Tue, 4 Aug 2015 04:39:03 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> From: Vincent Breitmoser To: IETF OpenPGP In-reply-to: <87io8v7uqt.fsf@littlepip.fritz.box> Date: Tue, 04 Aug 2015 04:42:41 +0200 Message-ID: <87h9of7p0e.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 02:43:07 -0000 > Maybe I missed an answer to this, but could someone please explain > what the point of finding a collision on a pgp fingerprint is, and > why we need to consider it as an attack scenario in the first plce? I could have been more clear here: I saw the previous answer, but the discussion went into the direction of collision feasibility without really answering dkg's doubts about whether this was even a reasonable scenario, and I'm not convinced it is. > Mallet joins an open source project which only takes the first 100 > bits for the fingerprint. He uploads the key for M1 to a keyserver. > > He then commits a large number of malicious patches using M2 for > authentication. These are all authenticated against his public key M2 > when he does the commit but the repository uses the key sent in band > and does not keep the key for later verification. So the premise here is: - a user uploads his key, but it is not actually used other than for its fingerprint - at authentication time, a public key sent by the user is used to check signatures, which is only checked to have the same fingerprint as the uploaded one - the implementation uses truncated fingerprints for this > At this point, any attempt to hold Mallet accountable is going to have > to rely on a human examining the logs and working out that Mallet must > have generated the malicious pair of keys. There is going to be no way > to unwind the thing automatically. And the actual attack is "slightly weaker non-repudiation"? - V From nobody Mon Aug 3 20:32:20 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE11A1B33DF for ; Mon, 3 Aug 2015 20:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 IBYqoEmEhCFx for ; Mon, 3 Aug 2015 20:32:17 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 E9A261B33BE for ; Mon, 3 Aug 2015 20:32:16 -0700 (PDT) Received: by lbqc9 with SMTP id c9so62456696lbq.1 for ; Mon, 03 Aug 2015 20:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=65hnQ6aHym1sQJjg5Yccv7TEZJkEnLqsBjqIHz0ncKo=; b=0YTxXyXowxEIIfcOM+xvCuM4gqXI5ayceaeTAMGPl1Zpg2CV7ieeSHWCKkcFL0YvYd 5m/FueMRnmyWCltdoiZGChkPiN0o2lZn6U/xf8LvzS3ZWcNvvD2FSdGenpixK98vjKZC d2wQ+bO2kcjR2vW+wHyZ3TWi6NbIYYMwHTo/ebU1ep5Ppfar/CA80JHI4/NaSpg1W0qH Hvxkdhg92UoYoOmAEUQGPgc/NLHzHEIMVsmACROgNLd2BCAgELpRkfXR7Bulf/xrodMO dG5h1tFAOHc/YkqJkSM0Mf9tqo8c0/lfqYHNYZ4jE+EncXIKaMbmi/MRVzeVgOrGSmT8 b/eQ== MIME-Version: 1.0 X-Received: by 10.152.21.71 with SMTP id t7mr1110391lae.118.1438659135386; Mon, 03 Aug 2015 20:32:15 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 3 Aug 2015 20:32:15 -0700 (PDT) In-Reply-To: <87h9of7p0e.fsf@littlepip.fritz.box> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> Date: Mon, 3 Aug 2015 23:32:15 -0400 X-Google-Sender-Auth: PqqU6h0RzBBaRuXD92RQ-PCe5z4 Message-ID: From: Phillip Hallam-Baker To: Vincent Breitmoser Content-Type: multipart/alternative; boundary=089e013d1fe4b7bcbd051c73ee63 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 03:32:18 -0000 --089e013d1fe4b7bcbd051c73ee63 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 3, 2015 at 10:42 PM, Vincent Breitmoser wrote: > > > Maybe I missed an answer to this, but could someone please explain > > what the point of finding a collision on a pgp fingerprint is, and > > why we need to consider it as an attack scenario in the first plce? > > I could have been more clear here: I saw the previous answer, but the > discussion went into the direction of collision feasibility without > really answering dkg's doubts about whether this was even a reasonable > scenario, and I'm not convinced it is. > > > Mallet joins an open source project which only takes the first 100 > > bits for the fingerprint. He uploads the key for M1 to a keyserver. > > > > He then commits a large number of malicious patches using M2 for > > authentication. These are all authenticated against his public key M2 > > when he does the commit but the repository uses the key sent in band > > and does not keep the key for later verification. > > So the premise here is: > - a user uploads his key, but it is not actually used other than for its > fingerprint > - at authentication time, a public key sent by the user is used to check > signatures, which is only checked to have the same fingerprint as the > uploaded one > - the implementation uses truncated fingerprints for this > > > At this point, any attempt to hold Mallet accountable is going to have > > to rely on a human examining the logs and working out that Mallet must > > have generated the malicious pair of keys. There is going to be no way > > to unwind the thing automatically. > > And the actual attack is "slightly weaker non-repudiation"? > The attack is to confuse someone's perl hack into letting someone get away with something they should not. --089e013d1fe4b7bcbd051c73ee63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 10:42 PM, Vincent Breitmoser &= lt;look@my.amazin= .horse> wrote:

> Maybe I missed an answer to this, but could someone please explain
> what the point of finding a collision on a pgp fingerprint is, and
> why we need to consider it as an attack scenario in the first plce?
I could have been more clear here: I saw the previous answer, but th= e
discussion went into the direction of collision feasibility without
really answering dkg's doubts about whether this was even a reasonable<= br> scenario, and I'm not convinced it is.

> Mallet joins an open source project which only takes the first 100
> bits for the fingerprint. He uploads the key for M1 to a keyserver. >
> He then commits a large number of malicious patches using M2 for
> authentication. These are all authenticated against his public key M2<= br> > when he does the commit but the repository uses the key sent in band > and does not keep the key for later verification.

So the premise here is:
- a user uploads his key, but it is not actually used other than for its =C2=A0 fingerprint
- at authentication time, a public key sent by the user is used to check =C2=A0 signatures, which is only checked to have the same fingerprint as th= e
=C2=A0 uploaded one
- the implementation uses truncated fingerprints for this

> At this point, any attempt to hold Mallet accountable is going to have=
> to rely on a human examining the logs and working out that Mallet must=
> have generated the malicious pair of keys. There is going to be no way=
> to unwind the thing automatically.

And the actual attack is "slightly weaker non-repudiation"= ?

The attack is to confuse someone'= s perl hack into letting someone get away with something they should not.
=C2=A0
--089e013d1fe4b7bcbd051c73ee63-- From nobody Mon Aug 3 23:45:32 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E20B1B3669 for ; Mon, 3 Aug 2015 23:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 GZImcHuzNV-Y for ; Mon, 3 Aug 2015 23:45:29 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A404F1B3667 for ; Mon, 3 Aug 2015 23:45:29 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZMVyZ-0000QX-Jj for ; Tue, 04 Aug 2015 08:45:27 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZMVxb-0002JU-N2; Tue, 04 Aug 2015 08:44:27 +0200 From: Werner Koch To: Vincent Breitmoser References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Vincent Breitmoser , IETF OpenPGP Date: Tue, 04 Aug 2015 08:44:27 +0200 In-Reply-To: <87h9of7p0e.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Tue, 04 Aug 2015 04:42:41 +0200") Message-ID: <87wpxbtuwk.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 06:45:31 -0000 On Tue, 4 Aug 2015 04:42, look@my.amazin.horse said: > And the actual attack is "slightly weaker non-repudiation"? ... when using a truncated fingerprint. Why should anyone truncate a fingerprint from 20 bytes to 13 bytes? This is an arbitrary value in between the known weak 8 byte keyids and the full 20 byte fingerprints for which we expect that in our lifetime collisions can be created. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 4 01:31:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3641A8AB1 for ; Tue, 4 Aug 2015 01:31:34 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6hAvfO5lRmOq for ; Tue, 4 Aug 2015 01:31:31 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 6D57C1A6F03 for ; Tue, 4 Aug 2015 01:31:31 -0700 (PDT) Received: by wibud3 with SMTP id ud3so166547418wib.1 for ; Tue, 04 Aug 2015 01:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dUdDmUbNSfDwl7JeJ+MkwWN4AfdVL056idsJKCy5euw=; b=Rarnhl+uG2g2NE19PuiAAPBTfTxyjJ6UdL+g6gQXsRpcx+eM/1DerQc3o83Lx89mtD YXoDFYMRCu/rxmsq8qmuOemz1JDo8qZJIWq81ICs5LKiErvEdJDc+vGacTHO0opfXdOb w04dKL142MkYxHwvwL73yfAieLeLseg81iUXQDD7omRH+j+jZbRFGQUR3d3c7S+7zsVE UP0BYbGX2cQZsiULJObmBpY3XsJMAR/hczm3UcJAmUut58rmztwuRcJ26qT7XOXb0wtE FKLw8VBJ90n+GfZkvbmi770YgLE8a3lrO1ImbH/xRhDErA21sHYTcuDMSbd1jLdyoBb3 e4zQ== MIME-Version: 1.0 X-Received: by 10.180.99.196 with SMTP id es4mr41300428wib.57.1438675503812; Tue, 04 Aug 2015 01:05:03 -0700 (PDT) Received: by 10.194.66.163 with HTTP; Tue, 4 Aug 2015 01:05:03 -0700 (PDT) In-Reply-To: <87wpxbtuwk.fsf@vigenere.g10code.de> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> Date: Tue, 4 Aug 2015 09:05:03 +0100 Message-ID: From: Nicholas Cole To: IETF OpenPGP Content-Type: multipart/alternative; boundary=f46d044283705a1574051c77be82 Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 08:31:34 -0000 --f46d044283705a1574051c77be82 Content-Type: text/plain; charset=UTF-8 On Tuesday, 4 August 2015, Werner Koch wrote: > On Tue, 4 Aug 2015 04:42, look@my.amazin.horse said: > > > And the actual attack is "slightly weaker non-repudiation"? > > ... when using a truncated fingerprint. > > Why should anyone truncate a fingerprint from 20 bytes to 13 bytes? > This is an arbitrary value in between the known weak 8 byte keyids and > the full 20 byte fingerprints for which we expect that in our lifetime > collisions can be > I'm really struggling to follow what is going on with this whole discussion! Fingerprints need to be robust enough that creating aritrary collisions is not feasible. That has always been central to OpenPGP. If that creates headaches for user interfaces then we will have to find ways to deal with that, but that is a separate discussion. I thought that there were some well established, secure as far as anyone knows, hash algorithms. We've many years experience of the problems of including or not including various extra bits of information along with the key material itself, so doesn't the WG just need to pick one of the candidate algorithms and have done with it? --f46d044283705a1574051c77be82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, 4 August 2015, Werner Koch <wk@gnupg.org> wrote:
On Tu= e,=C2=A0 4 Aug 2015 04:42, look@my.amazin.horse said:

> And the actual attack is "slightly weaker non-repudiation"?<= br>
... when using a truncated fingerprint.

Why should anyone truncate a fingerprint from 20 bytes to 13 bytes?
This is an arbitrary value in between the known weak 8 byte keyids and
the full 20 byte fingerprints for which we expect that in our lifetime
collisions can be=C2=A0

I'm really struggling to follow what i= s going on with this whole discussion!=C2=A0 Fingerprints need to be robust= enough that creating aritrary collisions is not feasible. That has always = been central to OpenPGP.=C2=A0 If that creates headaches for user interface= s then we will have to find ways to deal with that, but that is a separate = discussion.=C2=A0

I thought that there were some w= ell established, secure as far as anyone knows,=C2=A0hash algorithms. We= 9;ve many years experience of the problems of including or not including va= rious extra bits of information along with the key material itself, so does= n't the WG just need to pick one of the candidate algorithms and have d= one with it? =C2=A0


--f46d044283705a1574051c77be82-- From nobody Tue Aug 4 06:08:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2732F1A9084 for ; Tue, 4 Aug 2015 06:08:27 -0700 (PDT) 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] autolearn=ham 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 AjFVcGu7iH_h for ; Tue, 4 Aug 2015 06:08:21 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143: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 C09F61A9086 for ; Tue, 4 Aug 2015 06:08:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2F8E5E2035; Tue, 4 Aug 2015 09:08:11 -0400 (EDT) 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 15648-09; Tue, 4 Aug 2015 09:08:09 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 645B1E2034; Tue, 4 Aug 2015 09:08:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438693689; bh=CUZ0dI9Pn3gvHpB8Rgk7g/5jAKQaiG8IybxGgC0b02Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=cF4Vu2449abmNmxpMkfW+3rsBEcg/1kZ+ap+eEFwL64+teFgPFNt8aBEWNPBPgN7s l0YaNuyMAQMuOMTraU3cJXMMQm/2yEL0ZO3+NJpT43bGFwap1/1hinxjs0WcUZYsjS 0gvVXVTtQheH3WSYWDNALBNrUXPrrzyfeLq8xWcU= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t74D88QH015974; Tue, 4 Aug 2015 09:08:08 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> Date: Tue, 04 Aug 2015 09:08:08 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 3 Aug 2015 16:22:15 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Gregory Maxwell , IETF OpenPGP , Derek Atkins , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:08:27 -0000 Phillip Hallam-Baker writes: > Luckily my computations (which you unfortunately cut out) were based = on 30 > million attempts per second, so my results (the attack taking over a = year) > is still correct!=C2=A0 Indeed, your numbers are still 3x slower than= my > computation estimates. > > Your original assertion was broken. I don't think it very likely that som= eone > is going to spend more than a machine year to generate a vanity key unles= s they > can get someone else to pay for the time. Phill, it was *your* proposal that I was talking to, Mallet creating keys M1 and M2 to attack some open source project using PGP Signatures. So thank you for acknowledging that your original assertion was broken! My point was that particular notion isn't viable; nobody is going to expend that much effort just to be able to spoof a broken source control system. And moreover, a non-broken system (that uses the full fingerprint) is still out of reach even for stronger adversaries. > A hundred machine years for creating a key collision attack is completely > viable. It's only a hundred machine years for a 100-bit collision. A 160-bit collision is much much further out! > Also when we are talking about PGP Key fingerprint, the fingerprint is ov= er the > key binding and not just the key and so it is malleable.=C2=A0 I don't see how that helps (today) with SHA1 or SHA2. > I can well imagine someone making use of all that Bitcoin hardware for so= me > mischief. Hence a reason to go for SHA-2-512. > > Again, this is only a security consideration that has to be noted. > =C2=A0 -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 4 06:17:12 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B41A90DE for ; Tue, 4 Aug 2015 06:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 AhCK7hfhuNMq for ; Tue, 4 Aug 2015 06:17:09 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143: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 759C71A9145 for ; Tue, 4 Aug 2015 06:16:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 759C4E2035; Tue, 4 Aug 2015 09:16:56 -0400 (EDT) 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 16232-04; Tue, 4 Aug 2015 09:16:52 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 7D2A0E2034; Tue, 4 Aug 2015 09:16:52 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t74DGqJb016151; Tue, 4 Aug 2015 09:16:52 -0400 From: Derek Atkins To: Nicholas Cole References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> Date: Tue, 04 Aug 2015 09:16:52 -0400 In-Reply-To: (Nicholas Cole's message of "Tue, 4 Aug 2015 09:05:03 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:17:11 -0000 Nicholas Cole writes: > On Tuesday, 4 August 2015, Werner Koch wrote: > > On Tue,=C2=A0 4 Aug 2015 04:42, look@my.amazin.horse said: >=20=20=20=20 > > And the actual attack is "slightly weaker non-repudiation"? >=20=20=20=20 > ... when using a truncated fingerprint. >=20=20=20=20 > Why should anyone truncate a fingerprint from 20 bytes to 13 bytes? > This is an arbitrary value in between the known weak 8 byte keyids and > the full 20 byte fingerprints for which we expect that in our lifetime > collisions can be=C2=A0 > > I'm really struggling to follow what is going on with this whole discussi= on!=C2=A0 > Fingerprints need to be robust enough that creating aritrary collisions i= s not > feasible. That has always been central to OpenPGP.=C2=A0 If that creates = headaches > for user interfaces then we will have to find ways to deal with that, but= that > is a separate discussion.=C2=A0 > > I thought that there were some well established, secure as far as anyone > knows,=C2=A0hash algorithms. We've many years experience of the problems = of > including or not including various extra bits of information along with t= he key > material itself, so doesn't the WG just need to pick one of the candidate > algorithms and have done with it? =C2=A0 Every hash algorithm is going to have collisions. In an ideal hash you can find a collision in 2^(N/2) trials where N is the number of bits in the hash. If you truncate the hash then that reduces N. In non-ideal hashes it's less effort. > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Aug 4 07:49:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7321A0122 for ; Tue, 4 Aug 2015 07:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 uwDwQ9btufA3 for ; Tue, 4 Aug 2015 07:49:15 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 361BA1A011B for ; Tue, 4 Aug 2015 07:49:15 -0700 (PDT) Received: by lbbud7 with SMTP id ud7so7461229lbb.3 for ; Tue, 04 Aug 2015 07:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZTtLbIXnBA/oTo2f715pyikMz3GU1qOEIZC8TsFtbHQ=; b=s3pJguXSjyW0TAixKkx07RRGz0zZKyD5Hi2kMaQz0oJdjLnFYKkxCbyV6WflC+x+5c qQjV6U4ZhrimwzPc4tRiIYup3FaiH9FRgQJKx3u84D73I1Qjk8o7Yvo7wrMxJfLZjVEB dvfwGYg9y94dvPJ6A4SJbXk1tzoLi62rCX21NKNjDHV8ag249O+CUEL/ZzdM2YHbWebE lGtRTADD2K2AXp2LU7Lem5q1MABXd4+WeRbIzBfXFWA+s+YIUsQSPiox51uCRDYClPp4 dJS2TExLjWvet0c1Z5hb2fXuY59dWwGNoO+UCmyYmANVr1VbD1NWeYM6Zptbq1CZZXuu rd1g== MIME-Version: 1.0 X-Received: by 10.152.2.2 with SMTP id 2mr4060571laq.58.1438699753455; Tue, 04 Aug 2015 07:49:13 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 4 Aug 2015 07:49:13 -0700 (PDT) In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> Date: Tue, 4 Aug 2015 10:49:13 -0400 X-Google-Sender-Auth: XjezFLtGuZPTHn2wDkirmJz5ciw Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=089e013c6470be4713051c7d637f Archived-At: Cc: Gregory Maxwell , IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 14:49:17 -0000 --089e013c6470be4713051c7d637f Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 9:08 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > > > Luckily my computations (which you unfortunately cut out) were based > on 30 > > million attempts per second, so my results (the attack taking over a > year) > > is still correct! Indeed, your numbers are still 3x slower than my > > computation estimates. > > > > Your original assertion was broken. I don't think it very likely that > someone > > is going to spend more than a machine year to generate a vanity key > unless they > > can get someone else to pay for the time. > > Phill, it was *your* proposal that I was talking to, Mallet creating > keys M1 and M2 to attack some open source project using PGP Signatures. > That is not a vanity fingerprint, it is an attack. A vanity fingerprint would be doing a brute force search for a key whose fingerprint begins MINIO-Nxxxx-xxxxx-xxxxx-xxxxx Spending a hundred computer years to insert malware into an open source project is a much more probable attack. > So thank you for acknowledging that your original assertion was broken! > My point was that particular notion isn't viable; nobody is going to > expend that much effort just to be able to spoof a broken source control > system. And moreover, a non-broken system (that uses the full > fingerprint) is still out of reach even for stronger adversaries. The moral here is to use a sufficiently long fingerprint. But the point is that the fingerprint is indeed subject to birthday attack under rare circumstances. > > > A hundred machine years for creating a key collision attack is completely > > viable. > > It's only a hundred machine years for a 100-bit collision. A 160-bit > collision is much much further out! Yes, but if you didn't have to worry about a birthday attack at all, 80 bits would be acceptable by that metric. The point is that 80 bits is sufficient for a KeyID type use but a fingerprint should be at least 160 bits. 100/125 and 256 offer some safety margin. > > > Also when we are talking about PGP Key fingerprint, the fingerprint is > over the > > key binding and not just the key and so it is malleable. > > I don't see how that helps (today) with SHA1 or SHA2. If you are doing RSA, it greatly reduces the cost of a collision attack as you can avoid the need to generate new keypairs on each trial. But I don't think that is important as we are going to ECC in the near future anyway. --089e013c6470be4713051c7d637f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 4, 2015 at 9:08 AM, Derek Atkins <derek@ihtfp.com> wrote:
Phillip Hall= am-Baker <phill@hallambaker.com= > writes:

>=C2=A0 =C2=A0 =C2=A0Luckily my computations (which you unfortunately cu= t out) were based on 30
>=C2=A0 =C2=A0 =C2=A0million attempts per second, so my results (the att= ack taking over a year)
>=C2=A0 =C2=A0 =C2=A0is still correct!=C2=A0 Indeed, your numbers are st= ill 3x slower than my
>=C2=A0 =C2=A0 =C2=A0computation estimates.
>
> Your original assertion was broken. I don't think it very likely t= hat someone
> is going to spend more than a machine year to generate a vanity key un= less they
> can get someone else to pay for the time.

Phill, it was *your* proposal that I was talking to, Mallet creating=
keys M1 and M2 to attack some open source project using PGP Signatures.
=

That is not a vanity fingerprint, it is an= attack. A vanity fingerprint would be doing a brute force search for a key= whose fingerprint begins MINIO-Nxxxx-xxxxx-xxxxx-xxxxx

Spending a hundred computer years to insert malware into an open sour= ce project is a much more probable attack.

=C2=A0<= /div>
So thank you for acknowledging that your original assertion was broken!
My point was that particular notion isn't viable; nobody is going to expend that much effort just to be able to spoof a broken source control system.=C2=A0 And moreover, a non-broken system (that uses the full
fingerprint) is still out of reach even for stronger adversaries.

The moral here is to use a sufficiently long fingerp= rint. But the point is that the fingerprint is indeed subject to birthday a= ttack under rare circumstances.

=C2=A0

> A hundred machine years for creating a key collision attack is complet= ely
> viable.

It's only a hundred machine years for a 100-bit collision.=C2=A0= A 160-bit
collision is much much further out!

Yes, bu= t if you didn't have to worry about a birthday attack at all, 80 bits w= ould be acceptable by that metric.

The point is th= at 80 bits is sufficient for a KeyID type use but a fingerprint should be a= t least 160 bits. 100/125 and 256 offer some safety margin.
=C2= =A0

> Also when we are talking about PGP Key fingerprint, the fingerprint is= over the
> key binding and not just the key and so it is malleable.=C2=A0

I don't see how that helps (today) with SHA1 or SHA2.

If you are doing RSA, it greatly reduces the cost of = a collision attack as you can avoid the need to generate new keypairs on ea= ch trial. But I don't think that is important as we are going to ECC in= the near future anyway.
--089e013c6470be4713051c7d637f-- From nobody Tue Aug 4 08:49:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59291A1B34 for ; Tue, 4 Aug 2015 08:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 KGUHjMqWLRkV for ; Tue, 4 Aug 2015 08:49:16 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33571A1B22 for ; Tue, 4 Aug 2015 08:48:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8C818E2035; Tue, 4 Aug 2015 11:48:11 -0400 (EDT) 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 17487-01; Tue, 4 Aug 2015 11:48:09 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 630B7E2034; Tue, 4 Aug 2015 11:48:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438703289; bh=Ys7hYlzZRTbS5WAZTKDFycbwhEIvISBfzea1F9i28Uw=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=nOiMVG1a9RZ/OVohVY9DdHTl0ftNUkmEZpKwuH7b/kAZYOZWXecszjMrygqtDvmAD UGI96+2/PrM3fYpm5qDNcKw274tbZ5Q/0TlxAImQhMruhhqHOgWyXsqzjxzCbjVyHF ULakPS2tg6n07GkZhy0cqohYG+D+Ivv6SC9TpkFw= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t74Fm86X020019; Tue, 4 Aug 2015 11:48:08 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> Date: Tue, 04 Aug 2015 11:48:08 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 4 Aug 2015 10:49:13 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Gregory Maxwell , IETF OpenPGP , Derek Atkins , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 15:49:17 -0000 Phillip Hallam-Baker writes: > On Tue, Aug 4, 2015 at 9:08 AM, Derek Atkins wrote: > > Phillip Hallam-Baker writes: >=20=20=20=20 > >=C2=A0 =C2=A0 =C2=A0Luckily my computations (which you unfortunately= cut out) were based > on 30 > >=C2=A0 =C2=A0 =C2=A0million attempts per second, so my results (the = attack taking over a > year) > >=C2=A0 =C2=A0 =C2=A0is still correct!=C2=A0 Indeed, your numbers are= still 3x slower than my > >=C2=A0 =C2=A0 =C2=A0computation estimates. > > > > Your original assertion was broken. I don't think it very likely th= at > someone > > is going to spend more than a machine year to generate a vanity key > unless they > > can get someone else to pay for the time. >=20=20=20=20 > Phill, it was *your* proposal that I was talking to, Mallet creating > keys M1 and M2 to attack some open source project using PGP Signature= s. > > That is not a vanity fingerprint, it is an attack. A vanity fingerprint w= ould > be doing a brute force search for a key whose fingerprint begins > MINIO-Nxxxx-xxxxx-xxxxx-xxxxx The "MINIO-Nxxxx-..." vanity fingerprint issue is yet another issue you brought up, which is still different than this one. Yes, a vanity key fingerprint is definitely less work because there are many fewer bits that you care about. There's really no way to disallow it that I can see, but we should definitely remind people to always check the full fingerprint. > Spending a hundred computer years to insert malware into an open source p= roject > is a much more probable attack. I think you're mis-remembering your attack setup. The hundred computer-years effort is for someone to generate two keys that have the same matching truncated-to-100-bits fingerprint to use in a broken source code control system that only checks the truncated hash. But it's more than that; Mallet has to be trusted to actually push data into the source repository in the first place. For your attack scenario to succeed Mallet needs to generate both keys prior to being added to the project and only then will he be able to surrepticiously add code. Of course Mallet needs to have been trusted enough to get M1 added to the authorized commiters list first! My point is that finding an adversary that is trusted enough to get M1 added, and also a bad player such that they generated an M1 and M2, is probably going to be hard, because they have to control BOTH keys and generate them together. It also depends on this broken truncated-hash system. That's why I find that attack scenario unlikely. More likely Mallet would want to find a key that matches an already trusted key. This is NOT a collision attack but is a preimage attack; you know the hash result and need to find a second item that matches. Luckily that's still a 2^N and not a 2^(N/2) attack, so unachievable even with your 100-bit truncated hash system. > > So thank you for acknowledging that your original assertion was broke= n! > My point was that particular notion isn't viable; nobody is going to > expend that much effort just to be able to spoof a broken source cont= rol > system.=C2=A0 And moreover, a non-broken system (that uses the full > fingerprint) is still out of reach even for stronger adversaries. > > The moral here is to use a sufficiently long fingerprint. But the point i= s that > the fingerprint is indeed subject to birthday attack under rare circumsta= nces. I do agree with this. > > A hundred machine years for creating a key collision attack is comp= letely > > viable. >=20=20=20=20 > It's only a hundred machine years for a 100-bit collision.=C2=A0 A 16= 0-bit > collision is much much further out! > > Yes, but if you didn't have to worry about a birthday attack at all, 80 b= its > would be acceptable by that metric. > > The point is that 80 bits is sufficient for a KeyID type use but a finger= print > should be at least 160 bits. 100/125 and 256 offer some safety margin. Agreed, which is why we should tell people not to truncate! :) > > Also when we are talking about PGP Key fingerprint, the fingerprint= is > over the > > key binding and not just the key and so it is malleable.=C2=A0 >=20=20=20=20 > I don't see how that helps (today) with SHA1 or SHA2. > > If you are doing RSA, it greatly reduces the cost of a collision attack a= s you > can avoid the need to generate new keypairs on each trial. But I don't th= ink > that is important as we are going to ECC in the near future anyway. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 4 09:37:52 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A7E1A87B0 for ; Tue, 4 Aug 2015 09:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6n0QYU8h2HQg for ; Tue, 4 Aug 2015 09:37:49 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DC41A87A4 for ; Tue, 4 Aug 2015 09:37:49 -0700 (PDT) Received: from localhost (gate.ibr.cs.tu-bs.de [134.169.34.1]) by mail.mugenguild.com (Postfix) with ESMTPSA id 7A6E65FCE1; Tue, 4 Aug 2015 18:33:46 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> From: Vincent Breitmoser To: Phillip Hallam-Baker In-reply-to: Date: Tue, 04 Aug 2015 18:37:45 +0200 Message-ID: <87fv3z6mcm.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Gregory Maxwell , IETF OpenPGP , Derek Atkins , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 16:37:51 -0000 On 4 Aug 2015, Phillip Hallam-Baker wrote: > Spending a hundred computer years to insert malware into an open > source project is a much more probable attack. Your attack scenario has no implications on authentication properties, only non-repudiation. - V From nobody Tue Aug 4 14:12:47 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92221AC44C for ; Tue, 4 Aug 2015 14:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0vIS4M3CV6fP for ; Tue, 4 Aug 2015 14:12:45 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 50D3A1AC431 for ; Tue, 4 Aug 2015 14:12:45 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 715B3F984; Tue, 4 Aug 2015 17:12:42 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 39BB3202A2; Tue, 4 Aug 2015 23:12:32 +0200 (CEST) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , Vincent Breitmoser In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 04 Aug 2015 17:12:32 -0400 Message-ID: <878u9q4v27.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 21:12:46 -0000 On Mon 2015-08-03 23:32:15 -0400, Phillip Hallam-Baker wrote: > The attack is to confuse someone's perl hack into letting someone get away > with something they should not. This seems like an insufficiently specified attack to me. The same "someone" controls both (fingerprint-collided) keys anyway, so even if there's a "perl hack" involved, that someone is already authorized, right? can you please describe a more detailed attack scenario? --dkg From nobody Tue Aug 4 14:31:02 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1911ACD91 for ; Tue, 4 Aug 2015 14:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6-O1-Vku3Ets for ; Tue, 4 Aug 2015 14:31:00 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5731ACD84 for ; Tue, 4 Aug 2015 14:31:00 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C144DF984; Tue, 4 Aug 2015 17:30:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8AD392010F; Tue, 4 Aug 2015 23:30:49 +0200 (CEST) From: Daniel Kahn Gillmor To: Nicholas Cole , IETF OpenPGP In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 04 Aug 2015 17:30:49 -0400 Message-ID: <87614u4u7q.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 21:31:01 -0000 On Tue 2015-08-04 04:05:03 -0400, Nicholas Cole wrote: > I'm really struggling to follow what is going on with this whole > discussion! Fingerprints need to be robust enough that creating aritrary > collisions is not feasible. That has always been central to OpenPGP. Why must fingerprints be collision-resistant? We've always said that fingerprints need to be preimage-resistant -- that is, if i know your fingerprint, i should not be able to forge a new key that has the same fingerprint. But collision-resistance is a different property: if the fingerprint mechanism is not collision-resistant, then an attacker can create two keys with the same fingerprint. Why is this a threat? > If that creates headaches for user interfaces then we will have to > find ways to deal with that, but that is a separate discussion. I agree with this. > I thought that there were some well established, secure as far as anyone > knows, hash algorithms. We've many years experience of the problems of > including or not including various extra bits of information along with the > key material itself, so doesn't the WG just need to pick one of the > candidate algorithms and have done with it? The current OpenPGP fingerprint mechanism (in RFC 4880) uses SHA-1, which is a 160-bit digest. SHA-1's collision resistance is believed to be weaker than the 2^80 work factor that an ideal 160-bit digest should have. But that doesn't mean that it is necessarily "broken" for OpenPGP, if there is no way to exploit a collision atack on fingerprints in general. That said, the general cryptographic advice on SHA-1 is "don't use it", so while sticking with SHA-1 may not be a problem for this specific case, it is a distraction from the cryptanalysis to have to have this kind of discussion ("actually, maybe it's ok in this particular use") whenever it comes up. Our constraints in the WG here are also bound by UI concerns -- the fingerprint mechanism is one used by humans, and humans have a limited capacity to process and handle long high-entropy bitstrings (regardless of their representation). So we're really trying to navigate a multidimensional design space here when we talk about what to do for fingerprints. I'll try to start a new thread that identifies those choices more clearly, and ask people to weigh in on simpler questions about fingerprints rather than having everything tangled up. --dkg From nobody Tue Aug 4 18:48:09 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338201B2AE7 for ; Tue, 4 Aug 2015 18:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham 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 2kVJXphqdj3H for ; Tue, 4 Aug 2015 18:48:06 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E2D081B2AE4 for ; Tue, 4 Aug 2015 18:48:05 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 8F5CDF984; Tue, 4 Aug 2015 21:48:04 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4E5912010F; Wed, 5 Aug 2015 03:47:54 +0200 (CEST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" In-Reply-To: <87io98nucf.wl-neal@walfield.org> References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> <87io98nucf.wl-neal@walfield.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 04 Aug 2015 21:47:54 -0400 Message-ID: <87k2ta33qt.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Unuploadable Keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 01:48:08 -0000 On Sat 2015-07-25 11:13:36 -0400, Neal H. Walfield wrote: > I think this would make sharing non-exportable keys a pain, because it > overloads the meaning of local in a confusing way. Further, the > current mechanism is simply not enough to realize all interesting > policies. So, if we are forced to add something new, we should do it > properly. Consider the following two scenarios. > > When Alice wants to share her key with Bob, but not with the world, > she could sends it to him via email. To import her key, Bob has to do > something like: `gpg2 --import-options import-local'. There should be > no reason for Bob to have to do this in this situation. The policy > that Alice wants to implement is about exporting keys, not importing > them. When Bob wants to export Alice's key to forward it to Carol via > email, he needs to run `gpg2 --export-options export-local'. This is > annoying. Instead, when he exports the key, he should get a warning > or a prompt saying that Alice has indicated that this key shouldn't be > widely distributed. Of course, we can't enable `--import-options > import-local' and `--export-options export-local' by default, because > local signatures really shouldn't be imported or exported by default. these UI/UX difficulties seem like they're inherent in how GnuPG interacts with the "non-exportable" flag, but not necessarily a requirement from the OpenPGP protocol perspective. Maybe there are UI/UX improvements that could be done in GnuPG to treat these flags more conveniently? > The problem goes from a usability problem to a security problem when > we consider private key servers. Now, the private key server needs to > be configured to not discard local signatures. Are you aware that SKS currently doesn't discard local signatures at all? :( (see the link in my previous e-mail) > But, is this always the right decision? Sometimes signatures really > are local and should not be discarded or they are intended for a > different key server. I think you're saying that there should be an extra flag that is similar in semantics to the "non-exportable" flag, but that is slightly different. OpenPGP implementations should support both semantics. I worry that this would lead to more confusion, not less: Can a key be both "exportable" and "not for wide distribution"? what about a key that is marked as "local (non-exportable)" but also marked "for wide distribution"? how can we explain what these options mean to users? Or should we define a new value (other than 0 or 1) for the exportable subpacket? https://tools.ietf.org/html/rfc4880#section-5.2.3.11 I note that the spec doesn't say what to do if there are multiple Exportable Certification subpackets of different values in a single certification. >> would this interpretation of non-exportable self-sigs be >> a sufficient mechanism? > > I'm sorry, but I'm not clear on what definition you mean. I've read > your mail several times, but I can't figure it out. Can you please > repeat it. I just meant "would issuing only non-exportable self-sigs (as i proposed above) be sufficient to do what you're looking for?" -- you've answered this somewhat above with your concerns about the difficult ui/ux of --export-options export-local, etc, but it seems like that answer relates more to the GnuPG implementation than to the OpenPGP protocol. So i think the things we'd need to do to sort this out more clearly are: 0) figure out what the explicit semantics are (and how they differ from/relate to the existing exportable semantics) 1) figure out where they should apply -- should they belong to the primary key, to User IDs, or somewhere else? 2) figure out how to represent them in the bytes on the wire 3) come up with implementation guidance about how to handle keys/certs marked in this way. regards, --dkg From nobody Tue Aug 4 21:02:05 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980C51B2BD8 for ; Tue, 4 Aug 2015 21:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham 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 3BsF141kWg_V for ; Tue, 4 Aug 2015 21:02:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCEA1B2BD2 for ; Tue, 4 Aug 2015 21:02:01 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 68E01F984; Wed, 5 Aug 2015 00:01:58 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B7FCA1FF70; Wed, 5 Aug 2015 06:01:48 +0200 (CEST) From: Daniel Kahn Gillmor To: Paul Wouters , IETF OpenPGP In-Reply-To: References: <87bnf1hair.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 00:01:45 -0400 Message-ID: <87bnem2xjq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 04:02:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat 2015-07-25 08:56:09 -0400, Paul Wouters wrote: > [ dkg wrote: ] >> I looked at it with Petr Spacek after the meeting, and i plan on >> providing Paul with a more detailed review shortly. > > Greatly appreciated! heh, fsvo "shortly" :/ i'm not subscribed to dane@ietf.org, feel free to forward if you think this would be useful. key discovery vs key validation =2D------------------------------ As an optional key discovery mechanism for OpenPGP, i think this proposal has merit. I share Watson's concerns about "smuggling in a different trust model", but i have no complaints about DNSSEC validation being used as a corroborative validation mechanism, should clients choose to accept it for validation purposes. For clients that *don't* choose to accept it for validation purposes, they should validate the keys via their usual mechanisms, and rely on OPENPGPKEY records solely for discovery purposes. metadata leakage =2D--------------- I'm a little concerned about the potential for metadata leakage -- i don't want my MUAs to do DNS lookups every time i try to send mail to someone whose keys i dont have. Until DPRIVE is a reality (and maybe even after that) the DNS leaks much more information than my typical MUA =2D> MSA connection. (i like the metadata channel minimization offered by draft-moore-smtp-addrquery for that reason). localpart mangling =2D----------------- I have no strong preference for base32 vs. digested localpart for the hostname. Digested localparts require a little bit more work to invert than base32, but given the low entropy of typical normalized localparts, they don't provide a lot of protection against a determined attacker. I'm slightly more concerned with e-mail address length limits on base32 than on digested localparts -- a long localpart plus a long domain name could make for a very large DNS label, whereas a fixed digest should give us a fixed bound on size. In either case, some canonicalization will be required (before base32 or digest, whichever is chosen). fwiw, i believe that case normalization of the localpart is pragmatic for today's networks, despite not being within the letter of the RFC. I would advise clients to downcase before doing a lookup. The main advantage for base32 over digested localpart seems to be for synthesized OPENPGPKEY records in an online-signing DNSSEC-capable server. I don't believe this is a significant advantage for a key discovery mechanism for OpenPGP, because i believe some people will want to verify the OpenPGP certificate itself, regardless of its DNSSEC status, and the OpenPGP certificate won't have wildcards in it. RDATA content/structure =2D---------------------- The -03 spec =C2=A72.1 currently suggests that the RDATA should be an "RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public keyring" in any reusable way (see https://tools.ietf.org/html/rfc4880#section-3.6). =C2=A7 2.2 says: The RDATA Wire Format consists of a single OpenPGP public key as defined in Section 5.5.1.1 of [RFC4880]. Note that this format is without ASCII armor or base64 encoding. But 5.5.1.1 is *just* a public key packet. This is not a useful record to store. Instead what you want is probably exactly one "Transferable Public Key" (https://tools.ietf.org/html/rfc4880#section-11.1), which is the standard for the composable OpenPGP certificate format. But see the "Filtered Certificates" section below for more detail. Key Transitions =2D-------------- While i say "exactly one" Transferable Public Key, i'm assuming that the DNS is OK with serving multiple OPENPGPKEY records at a single label. This would be necessary for people to be able to handle a key transition. Some examples are: 0) Alice makes a new stronger primary key that she wants people to know about, while she continues to use her older, better-known key for several months. 1) Bob makes a new primary key using a new key algorithm (e.g. ECC) that he knows won't be universally supported. He publishes it alongside his more traditional (e.g. RSA) key. 2) Carol's longstanding key has been compromised. She revokes it, makes a new key, and wants to publish both the revoked certificate as well as her new cert. I think all of these cases can be served by multiple OPENPGPKEY records. Filtered Certificates =2D-------------------- Given that some users have aggregated OpenPGP certificates that are quite large (my own is currently ~475KB), we don't want to require people to publish their entire certificate in the DNS. Because OpenPGP certificates ("transferable public keys) are composable (they consist of a series of packets, many of which can be dropped), a reasonable policy for filtering the certificate for size purposes should be suggested. At a minimum, the OPENPGPKEY record for alice@example.com MUST contain: * primary key X - one User ID Y, SHOULD match 'alice@example.com' - self-signature from X, binding X to Y. [ note: I do not believe we need to require that the User ID MUST match the looked-up record, though it's obviously preferable to a validator if it does. ] This extremely minimal record might not provide an encryption-capable subkey, though, and the primary key may not be encryption-capable itself. So a more sensible transferable public key would also include all relevant subkeys: * primary key X - one User ID Y, SHOULD match 'alice@example.com' - self-signature from X, binding Y to X. - encryption-capable subkey Z - self-signature from X, binding Z to X. - [ other subkeys if relevant ...] Owners of the record may also want to include some up-to-date third-party certifications which they think would be helpful for validation, which would result in: * primary key X - one User ID Y, SHOULD match 'alice@example.com' - self-signature from X, binding Y to X. - third-party certification from V, binding Y to X - [ other third-party certifications if relevant ...] - encryption-capable subkey Z - self-signature from X, binding Z to X. - [ other subkeys if relevant ...] So when preparing these records for a specific OPENPGPKEYDATA with the goal of minimizing certificate size, a normal user would normally want to: 0) where one User ID from their cert matches the looked-up address, strip away non-matching User IDs and any certifications (self-sigs or third-party certs) associated with them 1) strip away all User Attribute packets and associated certifications 2) strip away all expired subkeys (may want to keep revoked subkeys if they were revoked prior to their preferred expiration to ensure that correspondents know they are properly revoked) 3) strip away all but the most recent self-sig for the remaining user IDs and subkeys 4) (optionally) strip away any uninteresting/unimportant third-party User ID certifications. This is a value judgement that will be made imperfectly, since the person creating the record doesn't know the trust model of the recipient. At the very least, the RDATA owner should strip all third-party ceritifcations which have been superceded by other certifications from the same third-party, as well as any expired third-party certs. Other useful filtering rules might include the date of the third-party cert (recent certs are better), strength of the third-party cert (stronger keys are better), the size of the third-party cert (smaller certs are better), "connectedness" of the third-party making the cert (e.g. based on some measurement of presence in the WoT strong set), or some domain-specific policy (e.g. always include third-party certs from the organization's internal CA key) With GnuPG, you can achieve a rough minimization with: gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengp= gpkey.pgp (this still exports expired subkeys and alternate User IDs, so further filtering could be done to make the record even smaller) Applying the most extreme of these minimization rules (with no third-party certifications whatever) my own OpenPGP certificate (with a single large primary key, a relatively long User ID, and three large subkeys) is < 4KiB. For even the largest ECC keys (nistp521) with a cert with distinct primary key and subkey, the filtered/minimized cert is well below 1KiB. does this make sense? I'm happy to discuss it further. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVwYqqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc0XUQALQEfpBjedf1mEA4qxhdc82n rVFQr/xVIYYeFNjemxVfOY0mn6uOJQpYa7WYSNSJ0g8Hyq97nMlvadwM2Yw4iduQ SKFAc0ItyBSaMxdEi7q68nVs46oltqIrbpuj/gBs/ouEnZ9SwHl4NIBxUTM+ESzS 5XIJc8xmxx9Ist1fIfOxN2geODRW6GpVJwr8/50F56WWGqsim1LuimlaSM6BTcwo /7rk5QdjLc2MYZ4cKF0/gJb0V2CSh5ysvQQMT5yCgOH/QZlV/JX5FK/Ey/E5jImJ BAYwDhgftHY87Zujsrrhky0vRorVPQsgGxpS0MtRgJea80GliJxvX70ijJA64LBU 1y7M5lDnKmFX3EdVaFcy2+SOhDBDub6ccHHCmHbponlKTLc65n5H/MgRntGjieBY XPqdgIBGl6X6HJPVkKnqKHVOYm2nZsSTZlKt01fElHu0kkrfZLMT5/FoPZfmzTC6 2Jg6piKWKsHQV2hZfC9PosGu7yHOCQQu3ZYTERvM8ACYUA9ox9O1SqZbiXfQwVYr CusNncPTiIhqxafA3ej1W3K9B2CwUuLFf4LO+hA3y25NpZHxGJuN7W5pZn9OFQdt sI/vDPObx+TltBymU20Z+I2XEQYd5/dSTaArxjOIJgHgd07wJjQ1h4GAuSrQS5oJ vfvkhBnpwC6Du2MMzvL5 =rDdg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 4 21:57:02 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4F31B29F9 for ; Tue, 4 Aug 2015 21:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5mGWHEfy9Xis for ; Tue, 4 Aug 2015 21:56:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F61B29B0 for ; Tue, 4 Aug 2015 21:56:58 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id EE169F984; Wed, 5 Aug 2015 00:56:57 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id DCDA92010F; Wed, 5 Aug 2015 06:56:47 +0200 (CEST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" In-Reply-To: <87h9osnswg.wl-neal@walfield.org> References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 00:56:47 -0400 Message-ID: <87wpxa1gfk.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 04:57:01 -0000 Hi Neal-- Thanks for this. Having a concrete proposal to work from is really useful. On Sat 2015-07-25 11:44:47 -0400, Neal H. Walfield wrote: > From 6160a4f49c23b35f8cc7105197ecb145aa6be9ad Mon Sep 17 00:00:00 2001 > From: "Neal H. Walfield" > Date: Sat, 25 Jul 2015 17:42:23 +0200 > Subject: [PATCH] RFC4880bis: Describe the superseceded-by notation. > > --- > misc/id/rfc4880bis/middle.mkd | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd > index 80c0a61..6465019 100644 > --- a/misc/id/rfc4880bis/middle.mkd > +++ b/misc/id/rfc4880bis/middle.mkd > @@ -1317,6 +1317,18 @@ addresses. > If there is a critical notation, the criticality applies to that > specific notation and not to notations in general. > > +The following notations are currently defined: > + > + superseded-by: This notation is used within a "Reason for > + Revocation" subpacket to indicate the key that superscedes this > + one. The value of the notation SHOULD be an OpenPGP message > + containing the fingerprint of the new key printed in > + hexadecimal form and signed with the new key. If no key > + supersedes this key, the value may instead be the 4 character > + ASCII string "none". This notation should only be respected if > + the "Reason for Revocation" subpacket does not indicate that > + the key was compromised (code: 2). > + > #### {5.2.3.17} Key Server Preferences > > (N octets of flags) A couple questions about this: * Why structure the notation data contents as human-readable text? for well-structured data, binary seems more efficient. * Why allow "none" -- if there is no key superceding the existing key, then this notation would simply not be present. * Why use the OpenPGP fingerprint? we're in the process of trying to improve things like designated revoker to avoid having cryptographic assertions bound to the fingerprint. What if we just included the full OpenPGP public key packet here instead? Implementations that care about the fingerprint can derive the fingerprint from the public key packet if they need to, but if we embed the full public key packet the cryptographic assertion doesn't need to depend on the strength of the fingerprinting mechanism. Regards, --dkg From nobody Wed Aug 5 01:14:54 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6B1B2D95; Wed, 5 Aug 2015 01:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xGhZlwIuicfg; Wed, 5 Aug 2015 01:14:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8EB1B2D9B; Wed, 5 Aug 2015 01:14:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mmQjL0kxWz3Mr; Wed, 5 Aug 2015 10:14:46 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=bazC9b8G X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1TNEIJsti9mc; Wed, 5 Aug 2015 10:14:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 5 Aug 2015 10:14:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EE90180042; Wed, 5 Aug 2015 04:14:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438762483; bh=p2hL40NnUX14BDCxI9RAEDgsbJNomDvMu3AdFnp1psI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bazC9b8GQe6XIJp/PqAqgX27v/pAtPAAn0buXkIwBjSC677Pe14UZYw9WH7tOjpU+ vUssRt23heMA89wwRb7m1gEAk3X1zPJcjFZkC7bezZvbex4Hs6YUqYOE5OWIy8On8L dUnfSRCGIZ965rMWlg5lGqplGzk+g5T/FHZ8Ysro= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t758EgMi008903; Wed, 5 Aug 2015 04:14:42 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 5 Aug 2015 04:14:42 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor In-Reply-To: <87bnem2xjq.fsf@alice.fifthhorseman.net> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:14:53 -0000 On Wed, 5 Aug 2015, Daniel Kahn Gillmor wrote: > i'm not subscribed to dane@ietf.org, feel free to forward if you think > this would be useful. [ I added dane back to the CC: as I think it will be useful to keep the openpgp discussion there too, as some people there also wanted a different specification of the RDATA ] > key discovery vs key validation > ------------------------------- > > As an optional key discovery mechanism for OpenPGP, i think this > proposal has merit. I share Watson's concerns about "smuggling in a > different trust model", but i have no complaints about DNSSEC validation > being used as a corroborative validation mechanism, should clients > choose to accept it for validation purposes. For clients that *don't* > choose to accept it for validation purposes, they should validate the > keys via their usual mechanisms, and rely on OPENPGPKEY records solely > for discovery purposes. The text does make it clear that you have that choice: The proposed new DNS Resource Record type is secured using DNSSEC. This trust model is not meant to replace the Trust Signature model. However, it can be used to encrypt a message that would otherwise have to be sent out unencrypted, where it could be monitored by a third party in transit or located in plaintext on a storage or email server. This method can also be used to obtain the OpenPGP public key which can then be used for manual verification. So there is no "smuggling".... DNSSEC is used to protect the transport, and as a poor man's better-than-nothing web-of-trust alternative. > metadata leakage > ---------------- > > I'm a little concerned about the potential for metadata leakage -- i > don't want my MUAs to do DNS lookups every time i try to send mail to > someone whose keys i dont have. The MUA can present you with information to manually verify or put a trust level to the key. The MUA should also cache negative attempts to get a key and limit these so avoid fingerprinting email send times by looking at DNS queries. That part is not in the current RRtype specification, but should go into the openpgpkey-usage document (co-authors wanted!) > localpart mangling > ------------------ > > I have no strong preference for base32 vs. digested localpart for the > hostname. Digested localparts require a little bit more work to invert > than base32, but given the low entropy of typical normalized localparts, > they don't provide a lot of protection against a determined attacker. And as clearly stated, were never meant to provide security. > I'm slightly more concerned with e-mail address length limits on base32 > than on digested localparts -- a long localpart plus a long domain name > could make for a very large DNS label, whereas a fixed digest should > give us a fixed bound on size. Do you forsee email addresses > 256/2 to be common use? > In either case, some canonicalization will be required (before base32 or > digest, whichever is chosen). fwiw, i believe that case normalization > of the localpart is pragmatic for today's networks, despite not being > within the letter of the RFC. I would advise clients to downcase before > doing a lookup. Thanks. I share that belief. > The main advantage for base32 over digested localpart seems to be for > synthesized OPENPGPKEY records in an online-signing DNSSEC-capable > server. I don't believe this is a significant advantage for a key > discovery mechanism for OpenPGP, because i believe some people will want > to verify the OpenPGP certificate itself, regardless of its DNSSEC > status, and the OpenPGP certificate won't have wildcards in it. Other people believe there is some use. If the only downside is not supporting insanely long email addresses, which I think are a more rare event, I think that it is okay. > RDATA content/structure > ----------------------- > > The -03 spec §2.1 currently suggests that the RDATA should be an > "RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public > keyring" in any reusable way (see > https://tools.ietf.org/html/rfc4880#section-3.6). > > > § 2.2 says: > > The RDATA Wire Format consists of a single OpenPGP public key as > defined in Section 5.5.1.1 of [RFC4880]. Note that this format is > without ASCII armor or base64 encoding. > > But 5.5.1.1 is *just* a public key packet. This is not a useful record > to store. > > Instead what you want is probably exactly one "Transferable Public Key" > (https://tools.ietf.org/html/rfc4880#section-11.1), which is the > standard for the composable OpenPGP certificate format. But see the > "Filtered Certificates" section below for more detail. I will update the reference to refer to that section. Thanks. That does look better. > Key Transitions > --------------- > > While i say "exactly one" Transferable Public Key, i'm assuming that the > DNS is OK with serving multiple OPENPGPKEY records at a single label. What is the advantage of multiple DNS records with 1 key over one DNS record with multiple keys? While I'm all four specifying one method to increase chances of interop, I'm not particularly set on one or the other solution. > Filtered Certificates > --------------------- > > Given that some users have aggregated OpenPGP certificates that are > quite large (my own is currently ~475KB), we don't want to require > people to publish their entire certificate in the DNS. Because OpenPGP > certificates ("transferable public keys) are composable (they consist of > a series of packets, many of which can be dropped), a reasonable policy > for filtering the certificate for size purposes should be suggested. We mention this in Section 5: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5 > At a minimum, the OPENPGPKEY record for alice@example.com MUST contain: > > * primary key X > - one User ID Y, SHOULD match 'alice@example.com' > - self-signature from X, binding X to Y. > > > [ note: I do not believe we need to require that the User ID MUST match > the looked-up record, though it's obviously preferable to a validator > if it does. ] > > This extremely minimal record might not provide an encryption-capable > subkey, though, and the primary key may not be encryption-capable > itself. > > So a more sensible transferable public key would also include all > relevant subkeys: > > * primary key X > - one User ID Y, SHOULD match 'alice@example.com' > - self-signature from X, binding Y to X. > - encryption-capable subkey Z > - self-signature from X, binding Z to X. > - [ other subkeys if relevant ...] > > > Owners of the record may also want to include some up-to-date > third-party certifications which they think would be helpful for > validation, which would result in: > > * primary key X > - one User ID Y, SHOULD match 'alice@example.com' > - self-signature from X, binding Y to X. > - third-party certification from V, binding Y to X > - [ other third-party certifications if relevant ...] > - encryption-capable subkey Z > - self-signature from X, binding Z to X. > - [ other subkeys if relevant ...] [...] > With GnuPG, you can achieve a rough minimization with: > > gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengpgpkey.pgp The idea was not to specify these policies in the DNS RRtype. Just tell people to keep to small keys. It did include an example gpg command in appendix A, but your command seems even better so I will update it. I would prefer not to mention specific key elements as those might change and are not really relevent for the DNS specification. Or perhaps these recommendations could go in the openpgpkey-usage document. Paul From nobody Wed Aug 5 04:28:33 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9C01B2FA1; Wed, 5 Aug 2015 04:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FY5ibOyLKQV7; Wed, 5 Aug 2015 04:28:28 -0700 (PDT) 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 B3E6D1B2FA3; Wed, 5 Aug 2015 04:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8AC9BE73; Wed, 5 Aug 2015 12:28:26 +0100 (IST) 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 QMiwOz39IQy6; Wed, 5 Aug 2015 12:28:26 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4CA1BDD0; Wed, 5 Aug 2015 12:28:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438774106; bh=Xr60cxx6GWZyuc1D793Tr80WOOIzJEzexBI3lvr7FUU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=syFXThxV1vkibLpNwr1hBAPyuxFbM9POcAiQ3UohV4mGCZn8j+kPavH+ildXigDcv icO1nYQC1orJSf6O71Q3Rb1h6UnejkF7FwfTpStBm9flo7NdqYItgLvkIXoNPKxLZS 7YcL2lfAdUgNa14Sggd6ojUFZKhQ+d3F8uOxy//w= Message-ID: <55C1F35A.5070904@cs.tcd.ie> Date: Wed, 05 Aug 2015 12:28:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Wouters , Daniel Kahn Gillmor References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 11:28:31 -0000 On 05/08/15 09:14, Paul Wouters wrote: >> >> >> I have no strong preference for base32 vs. digested localpart for the >> hostname. Digested localparts require a little bit more work to invert >> than base32, but given the low entropy of typical normalized localparts, >> they don't provide a lot of protection against a determined attacker. > > And as clearly stated, were never meant to provide security. Hmm. With no hats, I gotta say I prefer the harder to invert local part (i.e. hashed) to the reversible one (b32). If this experiment ends up successful, then I think we'll be setting a precedent for other per-user identifiers to be used as part of a DNS name so I do not believe that arguments about this aspect ought be decided solely based on PGP or SMIME or DANE. We should also consider that some other protocol is highly likely to follow what seems to have worked (just as _blah.example.com has been mimicked) and where we don't now know the privacy consequences of copying the pattern we're setting here. For that reason, I really would prefer that we stick to the hash and not go for the reversible per-user identifier. (Separately, I also don't buy that there will be much use for actually reversing the b32 encoding and if there were then the relevant work could just as easily be done in advance by a server that is willing to answer for a few known alternatives.) So sorry to continue an argument but shouldn't this experiment be a more conservative about privacy just in case it ends up wildly successful? Ta, S. From nobody Wed Aug 5 08:25:23 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B481A00E0; Wed, 5 Aug 2015 08:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OVo4AgLdUA11; Wed, 5 Aug 2015 08:25:13 -0700 (PDT) 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 974BD1B2A28; Wed, 5 Aug 2015 08:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CADE9BE88; Wed, 5 Aug 2015 16:25:08 +0100 (IST) 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 Vh6GFjukIvpH; Wed, 5 Aug 2015 16:25:08 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9FFDCBE55; Wed, 5 Aug 2015 16:25:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438788308; bh=G52SpfXnuuM9Qv9Myg5CU3LY2Y63olLshp+tGLF7oTY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=MH4SaHgyeU3S4VXoCgxCUSZSZRB4D5ryFGcAabaHoV0qB5msPXjElCzp5llZxikDA iNwVe+U8/nOVyP6zWE9JeO5Vdb8K72FQ2KUeaWmPRhIULMXKg8nYgwtOG0Qv8AP6oM S5i7AyxrtyaAVMTmU4AnAFwzQm2Zb9UvDo7/lXkE= Message-ID: <55C22AD4.5010709@cs.tcd.ie> Date: Wed, 05 Aug 2015 16:25:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Hoffman References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters , dane WG list , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:25:18 -0000 On 05/08/15 16:12, Paul Hoffman wrote: > Wearing my author hat: I don't care between b32 and hashing. Both are > equally easy to document. However: > > On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > >> So sorry to continue an argument but shouldn't this experiment be >> a more conservative about privacy just in case it ends up wildly >> successful? > > How is using the hash more conservative about privacy, except in zones > that are signed with NSEC instead of the more common NSEC3? If you > assume zones signed with NSEC3, both options are equally susceptible to > dictionary-based guessing attacks, given that the effort to create > search dictionaries for the billion of common LHS names is pretty low > even for hashes. Tempora. That on-path attacker has a far easier time reversing the b32 than anything based on the hash. Even with DPRIVE, we don't know how to handle the recursive to authoritative part. So a "putative other protocol that copies this" could well do a great job on hiding identifiers only to be caught out by following this b32 convention. I do accept that hashing doesn't make much difference for PGP or SMIME since the DNS answer in the success case almost certainly gives the game away, but I don't think that has to be true in general. The failure case may also be of interest though, with hashing, that DNS answer doesn't immediately tell the attacker to whom I'd like to send email. And I guess if some MUA adopts this there'll be quite a few negative answers for quite some time, so there's a privacy difference there I think. (Not sure if that was raised before - apologies if so.) S. > > --Paul Hoffman > > From nobody Wed Aug 5 10:16:06 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7F1A87B2 for ; Wed, 5 Aug 2015 10:16:05 -0700 (PDT) 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] autolearn=ham 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 hM5iagQSM2lw for ; Wed, 5 Aug 2015 10:16:02 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143: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 6A6091A87AB for ; Wed, 5 Aug 2015 10:16:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E6BAAE2036; Wed, 5 Aug 2015 13:16:00 -0400 (EDT) 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 27670-08; Wed, 5 Aug 2015 13:15:58 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 71709E2035; Wed, 5 Aug 2015 13:15:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438794958; bh=VfZ/IdxikTTRFPVRorUSLI7nKI3+eW3cqByUiyqa2Po=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ckpAWW7k0gngCr/X54ItvASFDyA8aEOozUVxLeMPW0hKqYHbeFbYPZVB9RRnEUo7y Uqo8VYSQpf1QrnJVXVkuvXS7AW7lJjZN6ex5pL20x9KAddqg0/uomMKjrld+FurwnE w7xzRY0FRZLv/L665Agd1cwYX2QVeR6oaCoKUhCo= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t75HFvS7002948; Wed, 5 Aug 2015 13:15:57 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> Date: Wed, 05 Aug 2015 13:15:57 -0400 In-Reply-To: <87614u4u7q.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 04 Aug 2015 17:30:49 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Nicholas Cole Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:16:05 -0000 Daniel Kahn Gillmor writes: > The current OpenPGP fingerprint mechanism (in RFC 4880) uses SHA-1, > which is a 160-bit digest. SHA-1's collision resistance is believed to > be weaker than the 2^80 work factor that an ideal 160-bit digest should > have. But that doesn't mean that it is necessarily "broken" for > OpenPGP, if there is no way to exploit a collision atack on fingerprints > in general. Indeed, while the SHA-1 collision resistance appears to be less than 2^80, there does not seem to be any known attacks that would make a preimage attack any easier, which means the way OpenPGP uses SHA-1 for fingerprints is still, technically, secure. The real issue is one of education. It's probably easier to move to SHA2 than explain why the OpenPGP use of SHA-1 for fingerprints isn't broken. > That said, the general cryptographic advice on SHA-1 is "don't use it", > so while sticking with SHA-1 may not be a problem for this specific > case, it is a distraction from the cryptanalysis to have to have this > kind of discussion ("actually, maybe it's ok in this particular use") > whenever it comes up. > > Our constraints in the WG here are also bound by UI concerns -- the > fingerprint mechanism is one used by humans, and humans have a limited > capacity to process and handle long high-entropy bitstrings (regardless > of their representation). So we're really trying to navigate a > multidimensional design space here when we talk about what to do for > fingerprints. > > I'll try to start a new thread that identifies those choices more > clearly, and ask people to weigh in on simpler questions about > fingerprints rather than having everything tangled up. > > --dkg -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 5 10:43:14 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF11B2F8E; Wed, 5 Aug 2015 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 IivP_sGwdvcO; Wed, 5 Aug 2015 08:12:17 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 342F41B2D82; Wed, 5 Aug 2015 08:12:17 -0700 (PDT) Received: from [10.32.60.120] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t75FC6Jf071674 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2015 08:12:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.120] From: "Paul Hoffman" To: "Stephen Farrell" Date: Wed, 05 Aug 2015 08:12:06 -0700 Message-ID: In-Reply-To: <55C1F35A.5070904@cs.tcd.ie> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Wed, 05 Aug 2015 10:43:13 -0700 Cc: Paul Wouters , dane WG list , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:12:18 -0000 Wearing my author hat: I don't care between b32 and hashing. Both are equally easy to document. However: On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > So sorry to continue an argument but shouldn't this experiment be > a more conservative about privacy just in case it ends up wildly > successful? How is using the hash more conservative about privacy, except in zones that are signed with NSEC instead of the more common NSEC3? If you assume zones signed with NSEC3, both options are equally susceptible to dictionary-based guessing attacks, given that the effort to create search dictionaries for the billion of common LHS names is pretty low even for hashes. --Paul Hoffman From nobody Wed Aug 5 10:43:16 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39D1A07BD; Wed, 5 Aug 2015 08:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 vewqDLmK45ga; Wed, 5 Aug 2015 08:56:14 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 0C6E11B30CA; Wed, 5 Aug 2015 08:56:09 -0700 (PDT) Received: from [10.32.60.120] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t75Fu0KI073394 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2015 08:56:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.120] From: "Paul Hoffman" To: "Stephen Farrell" Date: Wed, 05 Aug 2015 08:55:58 -0700 Message-ID: In-Reply-To: <55C22AD4.5010709@cs.tcd.ie> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Wed, 05 Aug 2015 10:43:13 -0700 Cc: Paul Wouters , dane WG list , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:56:15 -0000 On 5 Aug 2015, at 8:25, Stephen Farrell wrote: > On 05/08/15 16:12, Paul Hoffman wrote: >> Wearing my author hat: I don't care between b32 and hashing. Both are >> equally easy to document. However: >> >> On 5 Aug 2015, at 4:28, Stephen Farrell wrote: >> >>> So sorry to continue an argument but shouldn't this experiment be >>> a more conservative about privacy just in case it ends up wildly >>> successful? >> >> How is using the hash more conservative about privacy, except in >> zones >> that are signed with NSEC instead of the more common NSEC3? If you >> assume zones signed with NSEC3, both options are equally susceptible >> to >> dictionary-based guessing attacks, given that the effort to create >> search dictionaries for the billion of common LHS names is pretty low >> even for hashes. > > Tempora. That on-path attacker has a far easier time reversing the > b32 than anything based on the hash. Even with DPRIVE, we don't know > how to handle the recursive to authoritative part. Thanks, I was only thinking of off-path attackers. I agree that, if we are concerned with on-path watchers, hashes would preserve much more privacy than Base32 encodings. --Paul Hoffman From nobody Wed Aug 5 12:06:47 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20541A905B; Wed, 5 Aug 2015 12:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 URwTaDkK6wtY; Wed, 5 Aug 2015 12:06:41 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9C1A905E; Wed, 5 Aug 2015 12:06:40 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 28429F984; Wed, 5 Aug 2015 15:06:38 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CB56320053; Wed, 5 Aug 2015 21:06:28 +0200 (CEST) From: Daniel Kahn Gillmor To: Paul Wouters In-Reply-To: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 15:06:28 -0400 Message-ID: <877fp91rnv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:06:43 -0000 On Wed 2015-08-05 04:14:42 -0400, Paul Wouters wrote: > The text does make it clear that you have that choice: > > The proposed new DNS Resource Record type is secured using DNSSEC. > This trust model is not meant to replace the Trust Signature model. > However, it can be used to encrypt a message that would otherwise > have to be sent out unencrypted, where it could be monitored by a > third party in transit or located in plaintext on a storage or email > server. This method can also be used to obtain the OpenPGP public > key which can then be used for manual verification. > > So there is no "smuggling".... DNSSEC is used to protect the transport, > and as a poor man's better-than-nothing web-of-trust alternative. ah, right. Please don't use the term "Trust Signature model" here. While RFC 4880 does specify "trust signatures", they're not commonly used, and they don't represent the most common implementations of how people interact with OpenPGP's network of identity assertions (aka "web of trust") -- we don't want to conflate "Trust Signature" with "web of trust". >> metadata leakage >> ---------------- >> >> I'm a little concerned about the potential for metadata leakage -- i >> don't want my MUAs to do DNS lookups every time i try to send mail to >> someone whose keys i dont have. > > The MUA can present you with information to manually verify or put a > trust level to the key. i think you are referring to the validity of a key for a given e-mail address here. in OpenPGP-land, "trust" usually means something different (e.g., how much you're willing to rely on identity assertions made by the key itself, analogous to "is this X.509 cert a trust anchor?") > The MUA should also cache negative attempts to get a key and limit > these so avoid fingerprinting email send times by looking at DNS > queries. That part is not in the current RRtype specification, but > should go into the openpgpkey-usage document (co-authors wanted!) Sounds far more reasonable than query-on-every-message, though i'm not just worried about fingerprinting e-mail send times -- i'm also worried about tracking user associations directly by lookup. >> localpart mangling >> ------------------ >> >> I have no strong preference for base32 vs. digested localpart for the >> hostname. Digested localparts require a little bit more work to invert >> than base32, but given the low entropy of typical normalized localparts, >> they don't provide a lot of protection against a determined attacker. > > And as clearly stated, were never meant to provide security. Digested local parts provide a little more privacy, not security. But i agree it's only a little bit, given the low entropy of most localparts. Is it conceivable that someone wants to use a high-entropy localpart to avoid address leakage via key lookup? In that case, it seems like you'd do just as well to have your high-entropy localpart uniquely identify your key in the first place, with something like 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9@fifthhorseman.net. >> I'm slightly more concerned with e-mail address length limits on base32 >> than on digested localparts -- a long localpart plus a long domain name >> could make for a very large DNS label, whereas a fixed digest should >> give us a fixed bound on size. > > Do you forsee email addresses > 256/2 to be common use? you've dropped the units here -- 256/2 what? are we talking about characters or octets? if octets, under what encoding? I agree that e-mail addresses are rarely this long today, but we should be cautious and explicit about any additional constraints when we're proposing to mapp a limit from one domain (DNS) onto another domain (e-mail localparts). > Other people believe there is some use. If the only downside is not > supporting insanely long email addresses, which I think are a more > rare event, I think that it is okay. Steven's point about raising the cost slightly for passive attackers (e.g. TEMPORA) seems at least as relevant to me as the feasibility of online-signed zones serving up end-user OpenPGP certificates that can't possibly match the requested address exactly. That said, there's a separate scenario, where as a domain administrator i want to mint and sign an OpenPGP certificate on each query (even ones where i have no user), to avoid the possibility of someone enumerating all my actual users by walking the localpart space. minting a matching certificate would be creatable with the base32 approach (how would this work? something like the following: the DNS server responsible for these records would keep a domain-wide long-term secret. upon a query that it finds it has no legitimate record for, it would hash the query name and the long-term secret into a seed for a PRNG. from the PRNG output, it would deterministically derive secret key material and any other variable metadata (like creation date) needed to derive a new certificate. it could cache or discard these certificates as requested, because it could always re-generate them exactly from a new query. when a user opens a matching account, the user's personal key would replace the domain-generated one. i'm not saying this is a great system, just outlining how it might be done for a system that wants to keep its userbase hidden) I'm still on the fence here, as you can tell :P >> Key Transitions >> --------------- >> >> While i say "exactly one" Transferable Public Key, i'm assuming that the >> DNS is OK with serving multiple OPENPGPKEY records at a single label. > > What is the advantage of multiple DNS records with 1 key over one DNS > record with multiple keys? While I'm all four specifying one method to > increase chances of interop, I'm not particularly set on one or the > other solution. Hm, the more i think about it i find i prefer it aesthetically, but i'm not sure i have a good engineering argument. I don't see a great way to effectively prevent people from doing either one -- are there any DNS record types explicitly prohibit multiple records in response to a given query? OpenPGP composable certificates are just a series of OpenPGP packets concatenated; two certs concatenated together are themselves also just a series of OpenPGP packets by induction. We could say that the RDATA "MUST start with a Public Key Packet and MUST NOT contain more than one Public Key Packet". >> Filtered Certificates >> --------------------- >> >> Given that some users have aggregated OpenPGP certificates that are >> quite large (my own is currently ~475KB), we don't want to require >> people to publish their entire certificate in the DNS. Because OpenPGP >> certificates ("transferable public keys) are composable (they consist of >> a series of packets, many of which can be dropped), a reasonable policy >> for filtering the certificate for size purposes should be suggested. > > We mention this in Section 5: > > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5 looks sensible, though i think some of the terminology is slightly off there. i could try to provide patches for that section if you like. how is the draft developed -- how do you prefer edits sent to you? > The idea was not to specify these policies in the DNS RRtype. Just tell > people to keep to small keys. It did include an example gpg command > in appendix A, but your command seems even better so I will update it. > > I would prefer not to mention specific key elements as those might > change and are not really relevent for the DNS specification. Or perhaps > these recommendations could go in the openpgpkey-usage document. That seems OK to me as well. --dkg From nobody Wed Aug 5 12:32:37 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7260C1A0196; Wed, 5 Aug 2015 12:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6] autolearn=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 Oi4ZSiwMj0XP; Wed, 5 Aug 2015 12:32:35 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 222341A01E7; Wed, 5 Aug 2015 12:32:26 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B6665F984; Wed, 5 Aug 2015 15:32:24 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2EEAE2010F; Wed, 5 Aug 2015 21:32:14 +0200 (CEST) From: Daniel Kahn Gillmor To: Stephen Farrell , Paul Hoffman In-Reply-To: <55C22AD4.5010709@cs.tcd.ie> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 15:32:14 -0400 Message-ID: <874mkd1qgx.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Paul Wouters , dane WG list , IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:32:36 -0000 On Wed 2015-08-05 11:25:08 -0400, Stephen Farrell wrote: > Tempora. That on-path attacker has a far easier time reversing the > b32 than anything based on the hash. Even with DPRIVE, we don't know > how to handle the recursive to authoritative part. > > So a "putative other protocol that copies this" could well do a great > job on hiding identifiers only to be caught out by following this b32 > convention. > > I do accept that hashing doesn't make much difference for PGP or SMIME > since the DNS answer in the success case almost certainly gives the > game away, but I don't think that has to be true in general. > > The failure case may also be of interest though, with hashing, that DNS > answer doesn't immediately tell the attacker to whom I'd like to send > email. And I guess if some MUA adopts this there'll be quite a few > negative answers for quite some time, so there's a privacy difference > there I think. (Not sure if that was raised before - apologies if so.) yep, i raised that concern too, thanks for reinforcing it :) the cost of inverting a digest is definitely more than the cost of inverting b32, but it's unlikely to be difficult for an interested attacker to invert otherwise low-entropy domain names or localparts of e-mail addresses. see djb's writeup on nsec3walker for a related example of how low the bar is for doing large-scale hashing with the kind of low-entropy input spaces found in DNS: http://dnscurve.org/nsec3walker.html It's not exactly the same problem, but a good example of how small the protection is against a motivated adversary in this context. --dkg From nobody Thu Aug 6 01:24:04 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91C1B29C4; Thu, 6 Aug 2015 01:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 DgJiP6RYSnMN; Thu, 6 Aug 2015 01:23:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806791B29C2; Thu, 6 Aug 2015 01:23:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mn2sS3hmMz3Nf; Thu, 6 Aug 2015 10:23:56 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=sRWcBBIT X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Sr8nV4o6jK5Z; Thu, 6 Aug 2015 10:23:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Aug 2015 10:23:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C0290800B3; Thu, 6 Aug 2015 04:23:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438849434; bh=5cSel0yMtjakFg6uAzVu2zcUnUhD52zez2/QjOql84Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sRWcBBITR93cm0hBxJy8MWIRD5unHh7g1C7ghCw1rWOvrvdefhKc5pQsbHOH/Kibs ac9DgKKznXdUeC8rFONlJHMZImY0S34VQfivqn2FL1Zhdcy6tbbh5tEinwGbsGHXCZ rC6+FNN05T50mZIGKBb0HjwVliImmqek7BaJKt/k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t768NsEC019554; Thu, 6 Aug 2015 04:23:54 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Aug 2015 04:23:54 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <55C22D64.9080507@strotmann.de> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:24:01 -0000 On Wed, 5 Aug 2015, Carsten Strotmann wrote: > for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use > NSEC/NSEC3 "narrow" signing to prevent "zone-walking". email addresses are not secret. That is not the privacy you can protect at all. Anyone can either do a internet search or just attempt to deliver an email to figure out if the email address is valid. The only realy privacy concern is learning who is querying, meaning who is interested in mailing a particular user - assuming everything else on the email path is secureb by TLS, and the domain is large enough to actually hide the userbase (that is, nohats.ca is already a lost cause, because everyone knows a TLS connection to mx.nohats.ca means you are going to email me) > Breaking hashes requires much more "willful intent" than decoding BASE32. But that difference these days is basically zero as soon as someone puts up a module for johntheripper or hashcat or something on github. > The hashing communicates a "don't go here" message, even though it is > technically not a strong protection. If the sysadmin does not respect privacy on base32, they will not respect privacy on hash(very simple names) or even hash(former-lover) > It is like having a closed door vs. no door at all. No door communicates > "come in, no secrets, we're open" while the closed door (even if it can > be opened by minor force) communicates "private space". I might agree but I think the gain for this is so incredibly small, that I think the gain for use of online signers plus email address corrections by the smtp+dnssec combined server is actually a more likely and minorly useful thing to have. And don't get me wrong. I'd rather see zonefiles with a hash than with base32 cut from an esthetical point of view. Paul From nobody Thu Aug 6 01:50:05 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6476E1B2A13; Thu, 6 Aug 2015 01:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fV-F1OlNcUO1; Thu, 6 Aug 2015 01:50:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0A21ACE12; Thu, 6 Aug 2015 01:50:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY33393; Thu, 06 Aug 2015 08:50:00 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 09:49:53 +0100 From: Hosnieh Rafiee To: Paul Wouters Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAThlA= Date: Thu, 6 Aug 2015 08:49:53 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D6641@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:50:04 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Wouters >=20 > On Wed, 5 Aug 2015, Carsten Strotmann wrote: >=20 > > for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use > > NSEC/NSEC3 "narrow" signing to prevent "zone-walking". >=20 > email addresses are not secret. That is not the privacy you can protect > at all. Anyone can either do a internet search or just attempt to > deliver an email to figure out if the email address is valid. Disagree! This really depends on the person and scenarios.=20 For some people maybe it is not a problem to share their email addresses or= put them on their public websites because it is a part of their job. For e= xample a company shares its email to others so that other can contact them.= But for someone like a president of a country or a politician it is impor= tant because a criminal can bug them by threatening them, try to hack their= email by sending messages with fake links to do phishing attack or send co= des inside html body of the email to access their computer and infect it. T= herefore, from privacy point of view, as much information as I can have abo= ut a victim, the chance of attack is higher.=20 > The only realy privacy concern is learning who is querying, meaning who > is interested in mailing a particular user - assuming everything else > on the email path is secureb by TLS, and the domain is large enough to > actually hide the userbase (that is, nohats.ca is already a lost cause, > because everyone knows a TLS connection to mx.nohats.ca means you are > going to email me) Nope, some people who really care about their privacy uses different emails= for different purposes (business, family, friends). > > Breaking hashes requires much more "willful intent" than decoding > BASE32. >=20 > But that difference these days is basically zero as soon as someone > puts up a module for johntheripper or hashcat or something on github. Again disagree.=20 =20 Hosnieh From nobody Thu Aug 6 01:54:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E5B1B2A39; Thu, 6 Aug 2015 01:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9fsidvjvlBV8; Thu, 6 Aug 2015 01:54:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7201B2A33; Thu, 6 Aug 2015 01:54:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mn3Xh5LW7z3Nf; Thu, 6 Aug 2015 10:54:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=eK4Ar0JS X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2wWNJ-tdCu39; Thu, 6 Aug 2015 10:54:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Aug 2015 10:54:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CBC29800B3; Thu, 6 Aug 2015 04:54:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438851266; bh=Rjn9sNIKouiZpqO92bzNP403chbcNLexIH13TprNeA0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eK4Ar0JSqhQOx2wEtADUievWWmOrmrkuvWdv+nmAzf6Vm1C8eIHhvElpOdKKMQTpg Qny8KklALgCdnpyXnY6bBauCRls23G7S8ySuOLjZVNx92v9ZI8shW8YYM9n4kxeKx3 CmT0i45LZf06bF8MZO1U0i7svAbrfGnatrUoQWjg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t768sOQr025801; Thu, 6 Aug 2015 04:54:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Aug 2015 04:54:24 -0400 (EDT) From: Paul Wouters To: Jiankang Yao In-Reply-To: <20150806163914546863148@cnnic.cn> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, <20150806163914546863148@cnnic.cn> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:54:33 -0000 On Thu, 6 Aug 2015, Jiankang Yao wrote: > if there is a "email zone walking", the email spammer can use this feature to get the valid addrees easily and send trash emails. > If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret. So if you use NSEC3 and base32, they need to break the NSEC3 hashing, which has various parameters to make it easier or harder, but all are basically in the range of a few days of GPU cracking. If you use NSEC3 and sha256(LHS) then the work increase is basically making a table for every 8 letter combination and dictionary names which should be far less computations than the NSEC3 breaking. And to defend your email address against this, you have to make it so it is not easilly guessable with known names and that makes it harder to convey your email address verbally to other people - the exact opposite of what you want. Also, the only current alternative for people is to push their email address plaintext to a keyserver. So even with base32, we are increasing the privacy of email addresses of openpgp users. I really do believe that the hashing is not an affective security meassure. Paul From nobody Thu Aug 6 01:56:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFDB1B2A36; Thu, 6 Aug 2015 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XZkCJZhC_6T3; Thu, 6 Aug 2015 01:56:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331741B2A14; Thu, 6 Aug 2015 01:56:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY34125; Thu, 06 Aug 2015 08:56:07 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 09:56:01 +0100 From: Hosnieh Rafiee To: yaojk Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAVT5OAAAMvkA== Date: Thu, 6 Aug 2015 08:56:01 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D6656@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, <20150806163914546863148@cnnic.cn> In-Reply-To: <20150806163914546863148@cnnic.cn> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:56:16 -0000 From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Jiankang Yao >>=A0for=A0OPENPGPKEY/SMIMECERT=A0zones,=A0operators=A0could=A0(maybe=A0SHO= ULD)=A0use >>=A0NSEC/NSEC3=A0"narrow"=A0signing=A0to=A0prevent=A0"zone-walking". > >email=A0addresses=A0are=A0not=A0secret.=A0That=A0is=A0not=A0the=A0privacy= =A0you=A0can=A0protect >at=A0all.=A0Anyone=A0can=A0either=A0do=A0a=A0internet=A0search=A0or=A0just= =A0attempt=A0to >deliver=A0an=A0email=A0to=A0figure=A0out=A0if=A0the=A0email=A0address=A0is= =A0valid. > > =A0 >if there is a "email zone walking", the email spammer can use this feature= to get the valid addrees easily and send trash emails. >If we hope to prevent the spammer from getting the email address easily, t= he email address=A0should be regarded as secret. =A0 =A0 This is, IMO, a nightmare when using IPv6.... spammers sending email with = new IP and sometimes they know how to bypass the content filtering antispam= ming ... Hosnieh =20 From nobody Thu Aug 6 02:04:43 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98F11B2A39; Thu, 6 Aug 2015 02:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 twgLXDKU5Onf; Thu, 6 Aug 2015 02:04:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CD41B2A62; Thu, 6 Aug 2015 02:04:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZO37041; Thu, 06 Aug 2015 09:04:30 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 10:04:24 +0100 From: Hosnieh Rafiee To: Paul Wouters , Jiankang Yao Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAVT5P///M3AIAAEfCg Date: Thu, 6 Aug 2015 09:04:23 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D666D@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, <20150806163914546863148@cnnic.cn> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:04:41 -0000 Paul, > I really do believe that the hashing is not an affective security > meassure. >=20 By using hash, we make it harder for an attacker to find email addresses of= another person. Of course, we cannot prevent the attack.=20 Let me give you a real example from a real person that I name him Bob. Bob = hasn't published any email address on his personal website but he used a fo= rm so that others can send me email only via form. The spammer also tried to send hiim message via this form in a hope that th= ey can receive an answer so that they can have his email address. But Bob a= lso used other approaches such as captcha.=20 After that, he no longer received any spamming email because it was too eff= orts for spammer to check the captcha and take more of their time.=20 I hope it is clear, Hosnieh From nobody Thu Aug 6 02:30:22 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8BB1B2B31; Thu, 6 Aug 2015 02:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 81tcgOmxKtdr; Thu, 6 Aug 2015 02:30:19 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481791B2B16; Thu, 6 Aug 2015 02:30:18 -0700 (PDT) Received: from localhost (p5798E4D9.dip0.t-ipconnect.de [87.152.228.217]) by mail.mugenguild.com (Postfix) with ESMTPSA id 5261C5FCD5; Thu, 6 Aug 2015 11:26:14 +0200 (CEST) References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> From: Vincent Breitmoser To: Paul Wouters In-reply-to: Date: Thu, 06 Aug 2015 11:30:12 +0200 Message-ID: <87egjg7oij.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:30:21 -0000 On 6 Aug 2015, Paul Wouters wrote: > I might agree but I think the gain for this is so incredibly small, The same could be said about NSEC vs NSEC3 for a motivated attacker, and still NSEC received strong opposition. - V From nobody Thu Aug 6 02:58:33 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D4C1B2BC7; Thu, 6 Aug 2015 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 i-2whNdJI4kS; Thu, 6 Aug 2015 02:58:26 -0700 (PDT) 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 92F711B2BC8; Thu, 6 Aug 2015 02:58:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5449BE7D; Thu, 6 Aug 2015 10:58:24 +0100 (IST) 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 nZyuWe_zd5oB; Thu, 6 Aug 2015 10:58:24 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5998BE4C; Thu, 6 Aug 2015 10:58:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438855104; bh=CWhb7SlnpWA6USU/hLRHp5ZXCjXCHy41KJmSW15tcS8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=mwH09MlLhx1akvP89sCE/7hTObqNsopZkgo1fQXW1yo0ve31upPqpEB+NEZGrjQ2o ssNVWn9Tq7Cnc4l02oL9VJOh6vh7QVBF7YHtrdhzxHCxZjOG8tDXhOOZVRUUXGjjYZ KslIxyQnWK6KSvxMfbjGpTMsmn7iNhAwyXH5Xx0E= Message-ID: <55C32FBA.8080604@cs.tcd.ie> Date: Thu, 06 Aug 2015 10:58:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Wouters , dane WG list References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:58:30 -0000 Paul, On 06/08/15 09:23, Paul Wouters wrote: > On Wed, 5 Aug 2015, Carsten Strotmann wrote: > >> for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use >> NSEC/NSEC3 "narrow" signing to prevent "zone-walking". > > email addresses are not secret. That is not the privacy you can protect > at all. Anyone can either do a internet search or just attempt to > deliver an email to figure out if the email address is valid. That doesn't address my issue with this as a precedent. Nor the case of negative DNS responses trivially leaking that someone at my IP address wants to send a mail to at this time. (And yes, the trivially is a required part of the argument.) And "are not secret" isn't, I think, the right comparison. For me, the question is "if we want to experiment with user identifiers in DNS names, can we do it in the least privacy unfriendly, but yet practical, way as possible?" Yes, some people may oversell the benefits of hashing or may believe hashing is stronger than it is. Such mistaken beliefs however do not make hashing worse than b32. Hashing is still a bit better. > I might agree but I think the gain for this is so incredibly small, that > I think the gain for use of online signers plus email address > corrections by the smtp+dnssec combined server is actually a more likely > and minorly useful thing to have. Can you point me at a DNS server (or real specification for one) that generates responses in any similar fashion? I'm not aware of any that actually do, (even if they could do), but that my just be my ignorance. IMO even if there is a niche of DNS authoritative servers that can operate in that manner, requiring that that niche be used for the experiment makes it highly likely the experiment will fail. So my logic would be: if b32 is needed, the experiment will likely fail as you can't do it on many servers. If b32 is not needed, then let's just hash since that is less bad. > And don't get me wrong. I'd rather see zonefiles with a hash than with > base32 cut from an esthetical point of view. Well, let's do that then:-) S. > > Paul > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Thu Aug 6 03:43:47 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9DA1B2C51; Thu, 6 Aug 2015 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 U52vGmA_TY2Y; Thu, 6 Aug 2015 03:43:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2861B2C6E; Thu, 6 Aug 2015 03:43:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mn5yc1SSRz3Nm; Thu, 6 Aug 2015 12:43:36 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=VWpcEazm X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SeO7lRpMH3aQ; Thu, 6 Aug 2015 12:43:34 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Aug 2015 12:43:34 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CFBDC80042; Thu, 6 Aug 2015 06:43:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438857812; bh=mMNeIkMKtZqwJnAqKCRQPiaFUKiBDHZN2JGsoRmRQGs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VWpcEazmU4VJPfrH+ln5nLF/OclbYmp0sL36iblYfJ5gyWg5aKeTUB2+O8krg/wxJ tHlhBGhKh6hZ6F9xSi3Chb3JMwwog8Y8vcWArmcxjyO4Op3rkoezWPBqzgKBb40J1C en3nfu5vHHTOz6ZfEWtTIJQxuiW6+oJgyVSufgm8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t76AhVOM017440; Thu, 6 Aug 2015 06:43:32 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Aug 2015 06:43:31 -0400 (EDT) From: Paul Wouters To: Vincent Breitmoser In-Reply-To: <87egjg7oij.fsf@littlepip.fritz.box> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <87egjg7oij.fsf@littlepip.fritz.box> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:43:45 -0000 On Thu, 6 Aug 2015, Vincent Breitmoser wrote: >> I might agree but I think the gain for this is so incredibly small, > > The same could be said about NSEC vs NSEC3 for a motivated attacker, and > still NSEC received strong opposition. Actually, most users of NSEC3 care more about the OPT-OUT feature than the hashing feature. And there is no OPT-OUT with NSEC. Paul From nobody Thu Aug 6 08:27:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBBA1ACE84; Thu, 6 Aug 2015 01:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QdCMkBHpcBh2; Thu, 6 Aug 2015 01:39:25 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD9F1ACEA2; Thu, 6 Aug 2015 01:39:23 -0700 (PDT) Received: from healthyao-THINK (unknown [218.241.103.53]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMZU5HcNV0rCyBw--.7527S2; Thu, 06 Aug 2015 16:39:21 +0800 (CST) Date: Thu, 6 Aug 2015 16:39:20 +0800 From: "Jiankang Yao" To: "Paul Wouters" , dane References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20150806163914546863148@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart602551245372_=----" X-CM-TRANSID: AQAAf0ApMZU5HcNV0rCyBw--.7527S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZryUGFWkKFyrGFW8WF43GFg_yoW3WFc_Wa y8Wws7Ww4Yyrs7Kws3G3Wjkr48XayqgrWqy348Xr92vry3AFn7Za4vvFy7uF15JF4qv3sr KryfGw4IgrWagjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbTAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I26xC2 a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k0 4243AVC20s07MxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1l IxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr1l6VACY4 xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUxOJ5UUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: X-Mailman-Approved-At: Thu, 06 Aug 2015 08:27:28 -0700 Cc: IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:39:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart602551245372_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IFBhdWwgV291dGVycw0KRGF0ZTogMjAxNS0wOC0wNiAxNjoyMw0KVG86IGRhbmUg V0cgbGlzdA0KQ0M6IElFVEYgT3BlblBHUA0KU3ViamVjdDogUmU6IFtkYW5lXSBbb3BlbnBncF0g VGhlIERBTkUgZHJhZnQNCk9uIFdlZCwgNSBBdWcgMjAxNSwgQ2Fyc3RlbiBTdHJvdG1hbm4gd3Jv dGU6DQoNCj4+IGZvciBPUEVOUEdQS0VZL1NNSU1FQ0VSVCB6b25lcywgb3BlcmF0b3JzIGNvdWxk IChtYXliZSBTSE9VTEQpIHVzZQ0KPj4gTlNFQy9OU0VDMyAibmFycm93IiBzaWduaW5nIHRvIHBy ZXZlbnQgInpvbmUtd2Fsa2luZyIuDQo+DQo+ZW1haWwgYWRkcmVzc2VzIGFyZSBub3Qgc2VjcmV0 LiBUaGF0IGlzIG5vdCB0aGUgcHJpdmFjeSB5b3UgY2FuIHByb3RlY3QNCj5hdCBhbGwuIEFueW9u ZSBjYW4gZWl0aGVyIGRvIGEgaW50ZXJuZXQgc2VhcmNoIG9yIGp1c3QgYXR0ZW1wdCB0bw0KPmRl bGl2ZXIgYW4gZW1haWwgdG8gZmlndXJlIG91dCBpZiB0aGUgZW1haWwgYWRkcmVzcyBpcyB2YWxp ZC4NCj4NCj4NCg0KaWYgdGhlcmUgaXMgYSAiZW1haWwgem9uZSB3YWxraW5nIiwgdGhlIGVtYWls IHNwYW1tZXIgY2FuIHVzZSB0aGlzIGZlYXR1cmUgdG8gZ2V0IHRoZSB2YWxpZCBhZGRyZWVzIGVh c2lseSBhbmQgc2VuZCB0cmFzaCBlbWFpbHMuDQpJZiB3ZSBob3BlIHRvIHByZXZlbnQgdGhlIHNw YW1tZXIgZnJvbSBnZXR0aW5nIHRoZSBlbWFpbCBhZGRyZXNzIGVhc2lseSwgdGhlIGVtYWlsIGFk ZHJlc3Mgc2hvdWxkIGJlIHJlZ2FyZGVkIGFzIHNlY3JldC4NCg0KDQpKaWFua2FuZyBZYW8= ------=_001_NextPart602551245372_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
From: Paul Wouters<= /DIV>
Date: 2015-08-06 16:23
To: dane WG list
CC: IETF OpenPGP<= /DIV>
Subject: Re: [dane] [openpgp] The DANE draft
<= /DIV>
On Wed, 5 Aug 2015, Carsten Strotmann&n= bsp;wrote:
 
>> for OPENPGPKEY/SMIMECERT zones, operator= s could (maybe SHOULD) use
>> NSEC/NSEC3 "narrow" signing to prev= ent "zone-walking".
>
>email addresses are not secret. That&nbs= p;is not the privacy you can protect
>at all. Anyone can either do a = ;internet search or just attempt to
>deliver an email to figure out if&n= bsp;the email address is valid.
>
>
 
if there is a "email zone walking", the email spammer can use this fe= ature=20 to get the valid addrees easily and send trash emails.
If we hope to prevent the spammer from getting the email address easi= ly,=20 the email address should be regarded as secret.
 
 
Jiankang Yao
------=_001_NextPart602551245372_=------ From nobody Thu Aug 6 08:55:22 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E441B3010 for ; Thu, 6 Aug 2015 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7be4kUNdUEnU for ; Thu, 6 Aug 2015 08:55:19 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A07F1B2FF1 for ; Thu, 6 Aug 2015 08:55:19 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id E23566D7A7; Thu, 6 Aug 2015 11:55:17 -0400 (EDT) Message-ID: <55C3836D.2040104@iang.org> Date: Thu, 06 Aug 2015 16:55:25 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> In-Reply-To: <87614u4u7q.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:55:20 -0000 On 4/08/2015 22:30 pm, Daniel Kahn Gillmor wrote: > On Tue 2015-08-04 04:05:03 -0400, Nicholas Cole wrote: >> I'm really struggling to follow what is going on with this whole >> discussion! Fingerprints need to be robust enough that creating aritrary >> collisions is not feasible. That has always been central to OpenPGP. > > Why must fingerprints be collision-resistant? We've always said that > fingerprints need to be preimage-resistant -- that is, if i know your > fingerprint, i should not be able to forge a new key that has the same > fingerprint. > > But collision-resistance is a different property: if the fingerprint > mechanism is not collision-resistant, then an attacker can create two > keys with the same fingerprint. Why is this a threat? I'll bite: A person with two keys can sign a document that holds him, then announce that it wasn't signed by him. As proof, he can anonymously publish his other key... (What does this prove? Well, not a lot but it does spoil the normal narrative. Part of the success of a system is that it eliminates spoilers...) iang From nobody Thu Aug 6 09:08:37 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3CE1B3AE9 for ; Thu, 6 Aug 2015 09:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 cMA6upUxI8Me for ; Thu, 6 Aug 2015 09:08:34 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FC81B3B0D for ; Thu, 6 Aug 2015 09:08:06 -0700 (PDT) Received: from localhost (gate.ibr.cs.tu-bs.de [134.169.34.1]) by mail.mugenguild.com (Postfix) with ESMTPSA id 06C365FD99; Thu, 6 Aug 2015 18:04:01 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> From: Vincent Breitmoser To: ianG In-reply-to: <55C3836D.2040104@iang.org> Date: Thu, 06 Aug 2015 18:07:57 +0200 Message-ID: <87d1z0763m.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:08:36 -0000 On 6 Aug 2015, ianG wrote: > I'll bite: A person with two keys can sign a document that holds > him, then announce that it wasn't signed by him. Even though two keys exists with the same fingerprint, a signature made by one will only check out with that one, so creating ambiguous signatures is not that simple unless the attacker can also freely choose which one of the two keys will be used for verification. Also keep in mind that certificates are made over public key material, not only fingerprints. > As proof, he can anonymously publish his other key... Yes, well. He could also publish this key if it wasn't a collided one, or simply state that it was compromised. Which leads us to the same old discussion about the usefulness of non-repudiation in practice. - V From nobody Thu Aug 6 09:12:53 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFD11B3B0E for ; Thu, 6 Aug 2015 09:12:51 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GK5G_N1tON5N for ; Thu, 6 Aug 2015 09:12:50 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 A418E1B3B0C for ; Thu, 6 Aug 2015 09:12:49 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so29016754wic.1 for ; Thu, 06 Aug 2015 09:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lRoBN1h4+B4uV5JZOaoVe0Ov4N0bxBDhAK1WQtAFc+Y=; b=xxl9f9taoYtYcNFEQGKNy1dPeHdmPR+ab7pRJKOJN1wq5MlMkScJRzL9vJAQ83A9TI nzgfHspVqahDYWErgJkLPmdv2Mt2yRFAP19FWY5LAztjVcNa6wkw64Cvbx3rdH+jVs9y Rl6OyxPUFsagGVV55qWV0kB0O2uA/IQWrbJlYVOtzQVbkSqlwcKWcihrb7PTz0SLgscb T0TTRDqQntQKBq8b1FHhUhs/RAIGKrRP983nx/2eJr1Mu3lJVyS6Qr3K0mTWKBVLXiWh tmggL6artklXr2CpI0H+puASVm0mQW/yPadIab3TYTu1QwkYa5Uh3BvCg91iOoxyhXko IoeA== MIME-Version: 1.0 X-Received: by 10.194.109.97 with SMTP id hr1mr4913020wjb.38.1438877568423; Thu, 06 Aug 2015 09:12:48 -0700 (PDT) Received: by 10.194.66.163 with HTTP; Thu, 6 Aug 2015 09:12:48 -0700 (PDT) In-Reply-To: <87d1z0763m.fsf@littlepip.fritz.box> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> <87d1z0763m.fsf@littlepip.fritz.box> Date: Thu, 6 Aug 2015 17:12:48 +0100 Message-ID: From: Nicholas Cole To: Vincent Breitmoser Content-Type: multipart/alternative; boundary=089e01494b38575ce9051ca6ca77 Archived-At: Cc: "openpgp@ietf.org" , ianG Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:12:52 -0000 --089e01494b38575ce9051ca6ca77 Content-Type: text/plain; charset=UTF-8 On Thursday, 6 August 2015, Vincent Breitmoser wrote: > > On 6 Aug 2015, ianG wrote: > > > I'll bite: A person with two keys can sign a document that holds > > him, then announce that it wasn't signed by him. > > Even though two keys exists with the same fingerprint, a signature made > by one will only check out with that one, so creating ambiguous > signatures is not that simple unless the attacker can also freely choose > which one of the two keys will be used for verification. Also keep in > mind that certificates are made over public key material, not only > fingerprints. > > > As proof, he can anonymously publish his other key... > > Yes, well. He could also publish this key if it wasn't a collided one, > or simply state that it was compromised. Which leads us to the same old > discussion about the usefulness of non-repudiation in practice. > > There's actually just a more basic, practical problem. Most gpg tools assume unique fingerprints. Is it even possible to specify one key rather than another if both have the same fingerprint? --089e01494b38575ce9051ca6ca77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, 6 August 2015, Vincent Breitmoser <look@my.amazin.h= orse> wrote:

On 6 Aug 2015, ianG wrote:

> I'll bite: A person with two keys can sign a document that holds > him, then announce that it wasn't signed by him.

Even though two keys exists with the same fingerprint, a signature made
by one will only check out with that one, so creating ambiguous
signatures is not that simple unless the attacker can also freely choose which one of the two keys will be used for verification.=C2=A0 Also keep in=
mind that certificates are made over public key material, not only
fingerprints.

> As proof, he can anonymously publish his other key...

Yes, well.=C2=A0 He could also publish this key if it wasn't a collided= one,
or simply state that it was compromised.=C2=A0 Which leads us to the same o= ld
discussion about the usefulness of non-repudiation in practice.


There's actually just a more basic, pr= actical problem. Most gpg tools assume unique fingerprints. Is it even poss= ible to specify one key rather than another if both have the same fingerpri= nt?=C2=A0
--089e01494b38575ce9051ca6ca77-- From nobody Thu Aug 6 09:20:36 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA591B3B7E for ; Thu, 6 Aug 2015 09:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 OaEezLE7-orL for ; Thu, 6 Aug 2015 09:20:32 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719891B3B81 for ; Thu, 6 Aug 2015 09:20:31 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZNNu9-0005TO-L3 for ; Thu, 06 Aug 2015 18:20:29 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZNNtJ-0002HF-CT; Thu, 06 Aug 2015 18:19:37 +0200 From: Werner Koch To: ianG References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: ianG , openpgp@ietf.org Date: Thu, 06 Aug 2015 18:19:36 +0200 In-Reply-To: <55C3836D.2040104@iang.org> (iang@iang.org's message of "Thu, 06 Aug 2015 16:55:25 +0100") Message-ID: <87d1z0o0dj.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:20:35 -0000 On Thu, 6 Aug 2015 17:55, iang@iang.org said: > I'll bite: A person with two keys can sign a document that holds him, > then announce that it wasn't signed by him. As proof, he can > anonymously publish his other key... or publish his private key and claim that it has been stolen. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Aug 6 09:38:32 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4FB1B30FA for ; Thu, 6 Aug 2015 09:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 1jrvqfJG29Fr for ; Thu, 6 Aug 2015 09:38:29 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (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 375BF1B30FF for ; Thu, 6 Aug 2015 09:38:24 -0700 (PDT) Received: by labjt7 with SMTP id jt7so34960256lab.0 for ; Thu, 06 Aug 2015 09:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vDwZkbSKM6/UXudIxJEVh/XoJj2tGeGq2SUY9F6gFqA=; b=0R7hn7uWc5m+7F4EFHp+nCujwgWWYsoUhCm852c2FJ9/lSzxls22X5DhfxlmCJDHlx l57FzXPkybTBF0zUMEvqfWixsdYSH60924jkePNoMgRHQjil0E6ZSkh2YJp/DCRbX7T5 8UHy92e9ASo+oXBrvgdXQY/sY+bzkOH5Y1Iqae9NHabGeRoDCDj30r3jmW6/dRfJSx0M vNSzaL8/YuSNbr7Px8hFakv7CKx3aJ8qohx5fadGpVU89296fkQiD+2nBKw2dR0W+z9+ BMasNRQhYrv6cL4Xoy4OODIZxgE1tIvuz9V63ZbAeahruOK5cYB2pdJ47tMWmt3B7hyZ UJYg== MIME-Version: 1.0 X-Received: by 10.152.36.41 with SMTP id n9mr3164022laj.79.1438879102477; Thu, 06 Aug 2015 09:38:22 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 6 Aug 2015 09:38:22 -0700 (PDT) In-Reply-To: <87d1z0763m.fsf@littlepip.fritz.box> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> <87d1z0763m.fsf@littlepip.fritz.box> Date: Thu, 6 Aug 2015 12:38:22 -0400 X-Google-Sender-Auth: fvAJDvX0uBD-G-MkljN4w-wT8eE Message-ID: From: Phillip Hallam-Baker To: Vincent Breitmoser Content-Type: multipart/alternative; boundary=089e0158b608c73066051ca72555 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:38:31 -0000 --089e0158b608c73066051ca72555 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 12:07 PM, Vincent Breitmoser wrote: > > On 6 Aug 2015, ianG wrote: > > > I'll bite: A person with two keys can sign a document that holds > > him, then announce that it wasn't signed by him. > > Even though two keys exists with the same fingerprint, a signature made > by one will only check out with that one, so creating ambiguous > signatures is not that simple unless the attacker can also freely choose > which one of the two keys will be used for verification. Also keep in > mind that certificates are made over public key material, not only > fingerprints. > > > As proof, he can anonymously publish his other key... > > Yes, well. He could also publish this key if it wasn't a collided one, > or simply state that it was compromised. Which leads us to the same old > discussion about the usefulness of non-repudiation in practice. > Yes, I think we all understand the attack scope etc. pretty well at this point. The question is what to do about it and I think we actually have a practical consensus there as well. Remember that I am a systems guy looking to build stuff on top of stuff that is built on top of stuff. So for me the problem with a fingerprint that might or might not be vulnerable to attack is that I have to evaluate the security properties every time it is used and give reasons. The use of MD5 in HTTP-DIGEST authentication is perfectly secure even with the known flaws in MD5 etc. because the design intentionally uses a nested construction to guard against extension attacks and the low entropy of passwords means MD5 is never going to be the weakest link. But even so I gave up explaining to people why that was so about ten years ago because it just wasn't worth having the same argument again and again and again. Even pointing out that the scheme was designed that way only to get round the public key patents and there are much much better ways to do things does not end the argument. There are really two questions that the group needs to consider: 1) How many significant bits are necessary when printing a fingerprint on a business card? 2) How many internal bits should be preserved? The answer to 1 seems to be that 100 bits is the very lowest security level that is acceptable and 150 bits should be more than sufficient for OpenPGP uses. The work factor for impersonation of a key holder being 2^100 and 2^150 respectively. The answer to 2 is 'as many as you have available'. So even if there are only 150 bits printed on the business card, programs should store either the complete key parameters or the full digest output internally. The security considerations should mention the birthday attack so that reviewers know it has been considered and that the scope is limited to allowing an attacker to create a pair of colliding keys for their own use. The circumstances in which this could be exploited are very narrow and would depend on the attacker being able to cause two different systems to react differently to the same fingerprint. For example, imagine a debit system in which the account is identified by a fingerprint. Mallet creates a malicious keypair and ensures that the bank of Ethel has one and the bank of Gax has the other. Mallet then creates a money transfer order from his account at Ethel to his account at Gax which he signs with the Gax key. As soon as Gax has cleared the funds, Mallet transfers them out again (a few milliseconds later). When Gax tries to perform settlement against Ethel at the end of the day, Ethel rejects the transfer order because the signature doesn't verify. --089e0158b608c73066051ca72555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 12:07 PM, Vincent Breitmoser &= lt;look@my.amazin= .horse> wrote:

On 6 Aug 2015, ianG wrote:

> I'll bite: A person with two keys can sign a document that holds > him, then announce that it wasn't signed by him.

Even though two keys exists with the same fingerprint, a signature m= ade
by one will only check out with that one, so creating ambiguous
signatures is not that simple unless the attacker can also freely choose which one of the two keys will be used for verification.=C2=A0 Also keep in=
mind that certificates are made over public key material, not only
fingerprints.

> As proof, he can anonymously publish his other key...

Yes, well.=C2=A0 He could also publish this key if it wasn't a c= ollided one,
or simply state that it was compromised.=C2=A0 Which leads us to the same o= ld
discussion about the usefulness of non-repudiation in practice.

Yes, I think we all understand the attack scope et= c. pretty well at this point. The question is what to do about it and I thi= nk we actually have a practical consensus there as well.

Remember that I am a systems guy looking to build stuff on top of st= uff that is built on top of stuff. So for me the problem with a fingerprint= that might or might not be vulnerable to attack is that I have to evaluate= the security properties every time it is used and give reasons.=C2=A0

The use of MD5 in HTTP-DIGEST authentication is perfec= tly secure even with the known flaws in MD5 etc. because the design intenti= onally uses a nested construction to guard against extension attacks and th= e low entropy of passwords means MD5 is never going to be the weakest link.= But even so I gave up explaining to people why that was so about ten years= ago because it just wasn't worth having the same argument again and ag= ain and again. Even pointing out that the scheme was designed that way only= to get round the public key patents and there are much much better ways to= do things does not end the argument.


There are really two questions that the group needs to consider:

1) How many significant bits are necessary when printing = a fingerprint on a business card?

2) How many inte= rnal bits should be preserved?

The answer to 1 see= ms to be that 100 bits is the very lowest security level that is acceptable= and 150 bits should be more than sufficient for OpenPGP uses.=C2=A0 The wo= rk factor for impersonation of a key holder being 2^100 and 2^150 respectiv= ely.

The answer to 2 is 'as many as you have a= vailable'. So even if there are only 150 bits printed on the business c= ard, programs should store either the complete key parameters or the full d= igest output internally.

The security consideratio= ns should mention the birthday attack so that reviewers know it has been co= nsidered and that the scope is limited to allowing an attacker to create a = pair of colliding keys for their own use. The circumstances in which this c= ould be exploited are very narrow and would depend on the attacker being ab= le to cause two different systems to react differently to the same fingerpr= int.


For example, imagine a debit s= ystem in which the account is identified by a fingerprint. Mallet creates a= malicious keypair and ensures that the bank of Ethel has one and the bank = of Gax has the other. Mallet then creates a money transfer order from his a= ccount at Ethel to his account at Gax which he signs with the Gax key. As s= oon as Gax has cleared the funds, Mallet transfers them out again (a few mi= lliseconds later). When Gax tries to perform settlement against Ethel at th= e end of the day, Ethel rejects the transfer order because the signature do= esn't verify.


--089e0158b608c73066051ca72555-- From nobody Thu Aug 6 11:53:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6761ACD3E for ; Thu, 6 Aug 2015 11:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 NjM-lv6yw6jq for ; Thu, 6 Aug 2015 11:52:53 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90D61ACC85 for ; Thu, 6 Aug 2015 11:52:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 6EB5B6D71D; Thu, 6 Aug 2015 14:52:52 -0400 (EDT) Message-ID: <55C3AD0C.1060605@iang.org> Date: Thu, 06 Aug 2015 19:53:00 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] SHA3 is standardised as FIPS 202 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 18:53:00 -0000 It looks like SHA3 is now out as FIPS 202. http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf I think. Now, SHA3 or Keccak as it was better known, is built using the sponge construction idea. Included in the design are a couple of XOFs or extendable output functions called SHAKE128 and SHAKE256. I think these XOFs can be used as encryption algorithms in XOR-stream mode. Which brings us to a point worth thinking about. For a future OpenPGP release, we could use SHA3 for both the hash algorithm and the stream cipher. Etc. (There are supposed to be modes that you can do for authenticated encryption as well.) Which then gives us the opportunity to have ONE algorithm provide a much larger space of our needs. If we the SHA3 engine were to form the basis of all the symmetric needs, then this would provide for a minimal implementation with less code and less complexity. E.g., we could simply set the Mandatory to Implement (MTI) algorthm to the SHA3 family. Worthwhile? I'm not saying this will work - I'm just holding out the thought experiment that we could substantially ease the burden on developers and implementers if we could simplify the set down to one common family. iang From nobody Thu Aug 6 12:19:34 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9B1A8F45 for ; Thu, 6 Aug 2015 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 f_MURBAdqjvX for ; Thu, 6 Aug 2015 12:19:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CCAEC1A8AF4 for ; Thu, 6 Aug 2015 12:19:30 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 8E356F984; Thu, 6 Aug 2015 15:19:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id AADF920044; Thu, 6 Aug 2015 21:19:28 +0200 (CEST) From: Daniel Kahn Gillmor To: Nicholas Cole , Vincent Breitmoser In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> <87d1z0763m.fsf@littlepip.fritz.box> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 06 Aug 2015 15:19:24 -0400 Message-ID: <87lhdow7gj.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: "openpgp@ietf.org" , ianG Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 19:19:32 -0000 --=-=-= Content-Type: text/plain On Thu 2015-08-06 12:12:48 -0400, Nicholas Cole wrote: > There's actually just a more basic, practical problem. Most gpg tools > assume unique fingerprints. Is it even possible to specify one key rather > than another if both have the same fingerprint? but what are the consequences of this? If there's a specifically troubling scenario that puts other people at risk, we should be able to describe it. If there isn't, then this suggests that actually using two keys with the same fingerprint is a problem only for the person who holds the two keys, right? But that person has an easy (much cheaper in fact) way to proceed without the problem: don't make a fingerprint collision in the first place! --dkgp --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVw7M9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcW2oQANKw+VZmUaoS6Wk56a9OTU/j ikeudx2u1bcq6+BN6w64gv7a1epIUM99CZV4ygOggX+Y9HDuLCNSlFLoBruI71Ap X60xRM9x97N4w8vL2q3PLgF66HcgKJao8948AX9zVcxH+Kltsps+OrFA83Iw+QTQ 0qdoizDFsdzPsMzVb4RuahUuuGu7erlKz0FjBgoCc4rD8KDK0KCy+NmVaEoXjzRF ET8nwaUC09e1ayndggUdr3ILJ5GJNzc5VQD8o2EJCSVDPG6WzcbFfIvHPtANx+ls LD+K2ReWD2Oc/Td4fyqQDdrwZATY1LWU/izJH7NU7xo5UvLcvT5RGHmZSsPzvOTV hM6vIS73441vAzKuyZ8cFm7ClFdFGCqJGbv597QuUanvJK9/4WYncI7MyzGGJvWy GMhu+aSTPI5SVc7QRmZ3svozU/O2VB0R70Y3gzA1aWHcilCGq2lsoy0jhyLslYqS BcDw85zNAa4xXUJ4q2fe/VpeuBKbZeKeogabBPe0EY9Gv3x2urHARfeC1KOVhtu9 BzuxIagszxeoHGiXlPeiXfsVwa5asKxtS93CLI9nxt20cWpCJeUv3GIca3LD6/1I sEhDKYK6HX7OauGY/lh67OCVH0PIRLEoxffN62JxHI5VgdpARXZ1Wa8qwFyfiE9R /Z7TC2RezoMvMKtfUfRo =TH2p -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 6 13:19:18 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E71A87F1; Thu, 6 Aug 2015 13:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 rKMS75SipXDB; Thu, 6 Aug 2015 13:19:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 833EB1A1B66; Thu, 6 Aug 2015 13:19:15 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1F3E7F984; Thu, 6 Aug 2015 16:19:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C4B461FF70; Thu, 6 Aug 2015 22:19:12 +0200 (CEST) From: Daniel Kahn Gillmor To: Hosnieh Rafiee , Paul Wouters , Jiankang Yao In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7015D666D@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <20150806163914546863148@cnnic.cn> <814D0BFB77D95844A01CA29B44CBF8A7015D666D@lhreml504-mbs> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 06 Aug 2015 16:19:12 -0400 Message-ID: <877fp8w4ov.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [openpgp] [dane] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:19:17 -0000 On Thu 2015-08-06 05:04:23 -0400, Hosnieh Rafiee wrote: > Let me give you a real example from a real person that I name him > Bob. Bob hasn't published any email address on his personal website > but he used a form so that others can send me email only via form. > The spammer also tried to send hiim message via this form in a hope > that they can receive an answer so that they can have his email > address. But Bob also used other approaches such as captcha. > > After that, he no longer received any spamming email because it was > too efforts for spammer to check the captcha and take more of their > time. He will also receive no mail from me, because i prefer to mail from my own mail user agent, and not from webforms with a captcha, which have their own set of privacy concerns in common implementations, not to mention UI/UX issues. :P Plus, how does Bob reply to any of his mail? Does his reply use an e-mail address? What stops one recipient from publishing his e-mail address? But this all seems like quite a digression: how is this an argument about which form to use for publication of the OPENPGPKEY record? --dkg From nobody Thu Aug 6 18:20:18 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6251AD37C for ; Thu, 6 Aug 2015 18:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 PRxEYL9RaH86 for ; Thu, 6 Aug 2015 18:20:15 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 203A91AD377 for ; Thu, 6 Aug 2015 18:20:14 -0700 (PDT) Received: by labkb6 with SMTP id kb6so37494410lab.2 for ; Thu, 06 Aug 2015 18:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iK2lbyj4i5skSVAI0ll0qZtsP5ShDfcp1Jh7yOJEniE=; b=G67NJuAapNRpdjWPxq/jrVyw9+4ckZGGm3+QMZ58nmZEUHETHqYXlT5oEL1PrMOpcC f6WiDcXQ+HFrhZO+C5z3Lrrzp9bqlpbGl/n3WTc8LN/N4bt+CEO6iLn6WCwlw5CsWk1z LlVtOiUYQw38Bi573/q7XUyyMAqGDyZN40utgVtNr0PZnyhmGUg/TZoJlj0hKdL/xFJ3 IB5w/xwXRlv8JC8slR1JZ3dTRdWwZthGN0QxfWhxM6Eg3kS9LaRNV/3w9j0b5r6OhT72 qRr+Ze7NFz3voQmNrh+OANA0pHwfrtd3YxUcbZ2OPnqmsP3bz06GhKtPp+GJN6HiUvnv 7UsQ== MIME-Version: 1.0 X-Received: by 10.152.2.2 with SMTP id 2mr5193559laq.58.1438910412439; Thu, 06 Aug 2015 18:20:12 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 6 Aug 2015 18:20:12 -0700 (PDT) In-Reply-To: <87lhdow7gj.fsf@alice.fifthhorseman.net> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> <87d1z0763m.fsf@littlepip.fritz.box> <87lhdow7gj.fsf@alice.fifthhorseman.net> Date: Thu, 6 Aug 2015 21:20:12 -0400 X-Google-Sender-Auth: 9gMbHW2v0zy1JuMK9-o1AbDH8iY Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=089e013c6470ff47b3051cae6fe1 Archived-At: Cc: "openpgp@ietf.org" , Nicholas Cole , Vincent Breitmoser , ianG Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 01:20:16 -0000 --089e013c6470ff47b3051cae6fe1 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 3:19 PM, Daniel Kahn Gillmor wrote: > On Thu 2015-08-06 12:12:48 -0400, Nicholas Cole wrote: > > There's actually just a more basic, practical problem. Most gpg tools > > assume unique fingerprints. Is it even possible to specify one key rather > > than another if both have the same fingerprint? > > but what are the consequences of this? If there's a specifically > troubling scenario that puts other people at risk, we should be able to > describe it. > > If there isn't, then this suggests that actually using two keys with the > same fingerprint is a problem only for the person who holds the two > keys, right? > > But that person has an easy (much cheaper in fact) way to proceed > without the problem: don't make a fingerprint collision in the first > place! > Dan, The problem is that the person who is potentially at risk is not the key holder but the relying party who verifies the key. As with 'Domain Separation' it is a case where most of us prefer to be conservative unless there is a good reason to try the bleeding edge. Doubling the length of a printed fingerprint is clearly a problem. Having a big internal fingerprint isn't. Here, 100, 125 or 150 bits seem fine for a printed fingerprint and 256 bits is comfortable for an internal one. Do we really need to go further? My original goal was to avoid having to go into this explanation at last call. --089e013c6470ff47b3051cae6fe1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 3:19 PM, Daniel Kahn Gillmor &= lt;dkg@fifthhors= eman.net> wrote:
On Thu 2015-08-06 12:12:48 -0400, Nicholas Cole wrote:
> There's actually just a more basic, practical problem. Most gpg to= ols
> assume unique fingerprints. Is it even possible to specify one key rat= her
> than another if both have the same fingerprint?

but what are the consequences of this?=C2=A0 If there's a specif= ically
troubling scenario that puts other people at risk, we should be able to
describe it.

If there isn't, then this suggests that actually using two keys with th= e
same fingerprint is a problem only for the person who holds the two
keys, right?

But that person has an easy (much cheaper in fact) way to proceed
without the problem: don't make a fingerprint collision in the first place!

Dan,

Th= e problem is that the person who is potentially at risk is not the key hold= er but the relying party who verifies the key.

As = with 'Domain Separation' it is a case where most of us prefer to be= conservative unless there is a good reason to try the bleeding edge. Doubl= ing the length of a printed fingerprint is clearly a problem. Having a big = internal fingerprint isn't.

Here, 100, 125 or = 150 bits seem fine for a printed fingerprint and 256 bits is comfortable fo= r an internal one. Do we really need to go further? My original goal was to= avoid having to go into this explanation at last call.
=C2=A0
--089e013c6470ff47b3051cae6fe1-- From nobody Thu Aug 6 18:47:22 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5527D1B3E9D for ; Thu, 6 Aug 2015 18:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 Scq7ZwjA4ET8 for ; Thu, 6 Aug 2015 18:47:19 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACD21B3E98 for ; Thu, 6 Aug 2015 18:47:19 -0700 (PDT) Received: from pc1 (wsip-24-120-55-17.lv.lv.cox.net [::ffff:24.120.55.17]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 07 Aug 2015 03:47:16 +0200 id 0000000000000021.0000000055C40E24.000024D5 Date: Thu, 6 Aug 2015 18:47:25 -0700 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: openpgp@ietf.org Message-ID: <20150806184725.39b9d164@pc1> In-Reply-To: <55C3AD0C.1060605@iang.org> References: <55C3AD0C.1060605@iang.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-9429-1438912037-0001-2" Archived-At: Subject: Re: [openpgp] SHA3 is standardised as FIPS 202 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 01:47:21 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-9429-1438912037-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 06 Aug 2015 19:53:00 +0100 ianG wrote: > Which brings us to a point worth thinking about. For a future > OpenPGP release, we could use SHA3 for both the hash algorithm and > the stream cipher. Etc. (There are supposed to be modes that you > can do for authenticated encryption as well.) The keccak (aka sha3) authors submitted two proposals for authenticated encryption modes to the CAESAR competition: http://competitions.cr.yp.to/caesar-submissions.html (ketje and keyak) (caesar is a competition to find new authenticated encryption algs - it's currently in round 2, it's still some time until final results are expected - late 2017.) --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-9429-1438912037-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVxA4tAAoJEKWIAHK7tR5CpmIQAL24n430RcGXzRLtzftzwkol EflH5sM2K7nrmKvdD73kn5e31WOGMiBNr4pPIYTYwHbNoUn+6S0x/2MybmNG8NSJ IxV/N6IstIBryb5UeDGkZxWqN+/zq2ZG7TWB9g0oNlaUKo/6kECKiFQkuDMzmAHc MiaZ0l0NVgi2jWI5dy7ffe4EfqrTKXDbyCJcc8WdYnusbu40E9tA4w61mLsaMx2V Nms97r8OParpYU+kDzRAilg7FmipMS3XRVVJjEEPLxuaa1BL9HXnXPmHrZHX9pkx f0Mp34QOsGjG9VcrH9CWCIxMrjbJYwF5HbcDd3gcHCEor0XF0+C45MnbMHJKXIKc QTDgpjYcHHr8ZcL8Rv3xktrRziSsZitIY1MbWNeOFhbH/7F7+SaQV1d1phIz2sqX 5lK16Twj1+X7ak+s5cuurklJysjuh1Zjsvi+ttoDFCNJHuC8B+HnhjEiwx9XlTFv 0h6o0PbCNr9iUtYN29FP2SlKkcH9lcJ3EaEb5OrpG5poqpBTUpnas+Ydlwtxarr4 4jt0fJtzj/4isfSdoslrK4KIPi8FU3mpG4sFuA4LzzSu2E4u4OAE4hCgUPeBtP0J VJXOTLNSjfUBDH8pM6FbDprDujGTWQNeIc0xksktAwfKrEJzd52G4Yg8ShN4ar51 fla9U4n4+Ef0mQsKnpd2 =WqnE -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-9429-1438912037-0001-2-- From nobody Thu Aug 6 19:06:40 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE0C1B35CC for ; Thu, 6 Aug 2015 19:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 r2GOtrVXbhYq for ; Thu, 6 Aug 2015 19:06:37 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFCD1B35CE for ; Thu, 6 Aug 2015 19:06:36 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 810CE6D73C; Thu, 6 Aug 2015 22:06:35 -0400 (EDT) Message-ID: <55C412B3.8070706@iang.org> Date: Fri, 07 Aug 2015 03:06:43 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87twsn2wcz.fsf@vigenere.g10code.de> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> <87d1z0763m.fsf@littlepip.fritz.box> <87lhdow7gj.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 02:06:38 -0000 On 7/08/2015 02:20 am, Phillip Hallam-Baker wrote: > > > On Thu, Aug 6, 2015 at 3:19 PM, Daniel Kahn Gillmor > > wrote: > > On Thu 2015-08-06 12:12:48 -0400, Nicholas Cole wrote: > > There's actually just a more basic, practical problem. Most gpg tools > > assume unique fingerprints. Is it even possible to specify one key rather > > than another if both have the same fingerprint? > > but what are the consequences of this? If there's a specifically > troubling scenario that puts other people at risk, we should be able to > describe it. > > If there isn't, then this suggests that actually using two keys with the > same fingerprint is a problem only for the person who holds the two > keys, right? > > But that person has an easy (much cheaper in fact) way to proceed > without the problem: don't make a fingerprint collision in the first > place! > > > Dan, > > The problem is that the person who is potentially at risk is not the key > holder but the relying party who verifies the key. > > As with 'Domain Separation' it is a case where most of us prefer to be > conservative unless there is a good reason to try the bleeding edge. > Doubling the length of a printed fingerprint is clearly a problem. > Having a big internal fingerprint isn't. > > Here, 100, 125 or 150 bits seem fine for a printed fingerprint and 256 > bits is comfortable for an internal one. Do we really need to go > further? My original goal was to avoid having to go into this > explanation at last call. Are we arguing about a shortened internal identifier for the key? That's easy. The full hash, please. iang From nobody Fri Aug 7 03:06:59 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B351B3835 for ; Fri, 7 Aug 2015 03:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WQ6qho7ZfoBC for ; Fri, 7 Aug 2015 03:06:56 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565161B3834 for ; Fri, 7 Aug 2015 03:06:55 -0700 (PDT) Received: from localhost (p57B2C6A4.dip0.t-ipconnect.de [87.178.198.164]) by mail.mugenguild.com (Postfix) with ESMTPSA id 3741D5FCD4; Fri, 7 Aug 2015 12:02:50 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> <9c2c8c5df67c83925d7e3c21fe943483.squirrel@mail2.ihtfp.org> <20150803173231.GG3067@straylight.m.ringlet.net> <2439a89a6c4eb70044e144406a732482.squirrel@mail2.ihtfp.org> <87io8v7uqt.fsf@littlepip.fritz.box> <87h9of7p0e.fsf@littlepip.fritz.box> <87wpxbtuwk.fsf@vigenere.g10code.de> <87614u4u7q.fsf@alice.fifthhorseman.net> <55C3836D.2040104@iang.org> <87d1z0763m.fsf@littlepip.fritz.box> <87lhdow7gj.fsf@alice.fifthhorseman.net> From: Vincent Breitmoser To: Phillip Hallam-Baker In-reply-to: Date: Fri, 07 Aug 2015 12:06:49 +0200 Message-ID: <878u9n76py.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 10:06:58 -0000 On 7 Aug 2015, Phillip Hallam-Baker wrote: > Here, 100, 125 or 150 bits seem fine for a printed fingerprint and > 256 bits is comfortable for an internal one. Do we really need to go > further? I'm not even sure what an "internal" fingerprint is supposed to be, or where it is supposed to be used. A fingerprint is the one true unique identifier for a key, diverging from this "internally" misses the point of that. I also agree with Werner on the aspect that the openpgp rfc should specify what a fingerprint is purely from a data perspective. How it is printed or otherwise represented is not something we should go into there. - V From nobody Sat Aug 8 02:25:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CF81AC414 for ; Sat, 8 Aug 2015 02:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 opbFRcz1e5gG for ; Sat, 8 Aug 2015 02:25:31 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DDD1AC413 for ; Sat, 8 Aug 2015 02:25:31 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZO0Nd-0007zi-43 for ; Sat, 08 Aug 2015 11:25:29 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZO0Jl-0007mj-Km for ; Sat, 08 Aug 2015 11:21:29 +0200 From: Werner Koch To: openpgp@ietf.org Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: openpgp@ietf.org Date: Sat, 08 Aug 2015 11:21:29 +0200 Message-ID: <87y4hmi19i.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 09:25:33 -0000 Hi! Now that an official SHA3 specs has been published I would like to see algorithm ids assigned. Although it is some time until we can publish rfc-4880bis, it would be useful to agree on the algorithm ids now. This would be helpful for experimental implementations. Thus what about this new table with the SHA2 drop in replacements: ID Algorithm Text Name -- --------- --------- 1 - MD5 [HAC] "MD5" 2 - SHA-1 [FIPS180] "SHA1" 3 - RIPE-MD/160 [HAC] "RIPEMD160" 4 - Reserved 5 - Reserved 6 - Reserved 7 - Reserved 8 - SHA256 [FIPS180] "SHA256" 9 - SHA384 [FIPS180] "SHA384" 10 - SHA512 [FIPS180] "SHA512" 11 - SHA224 [FIPS180] "SHA224" 12 - SHA3-224 [FIPS202] "SHA3-224" 13 - SHA3-256 [FIPS202] "SHA3-256" 14 - SHA3-384 [FIPS202] "SHA3-384" 15 - SHA3-512 [FIPS202] "SHA3-512" 100 to 110 - Private/Experimental algorithm Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224 and thus it ended up out of order. I am not sure about the text name. Is a dash okay (cf. armor header)? The OIDS are: The hexadecimal representations for the currently defined hash algorithms are as follows: [...] - SHA3-224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07 - SHA3-256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08 - SHA3-384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x09 - SHA3-512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a The ASN.1 Object Identifiers (OIDs) are as follows: [...] - SHA3-224: 2.16.840.1.101.3.4.2.7 - SHA3-256: 2.16.840.1.101.3.4.2.8 - SHA3-384: 2.16.840.1.101.3.4.2.9 - SHA3-512: 2.16.840.1.101.3.4.2.10 The full hash prefixes for these are as follows: [...] SHA3-224: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, 0x00, 0x04, 0x40 SHA3-256: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, 0x00, 0x04, 0x40 SHA3-384: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, 0x00, 0x04, 0x40 SHA3-512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, 0x00, 0x04, 0x40 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat Aug 8 05:43:30 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DCB1A872C for ; Sat, 8 Aug 2015 05:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0JILihXrf72E for ; Sat, 8 Aug 2015 05:43:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3FC61A7017 for ; Sat, 8 Aug 2015 05:43:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mpNWv57MZz3PG; Sat, 8 Aug 2015 14:43:23 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=TPkEgfF4 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Mm9GhnJDnTXX; Sat, 8 Aug 2015 14:43:21 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 8 Aug 2015 14:43:21 +0200 (CEST) Received: from [192.168.0.16] (a11209.upc-a.chello.nl [62.163.11.209]) by bofh.nohats.ca (Postfix) with ESMTPSA id B402E800B3; Sat, 8 Aug 2015 08:43:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1439037800; bh=0aWTn7YPka0CDLCWSr2wpsGf3fk5NmlHAdcGzBSbcbA=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=TPkEgfF4obyjIFlckWkoybVkcbOKuHwtBcRcmYgbj2MGWaXjlpMS2G/IpqIo2WAes 4hzFuVSjurN8nayvotrKqJhh7KM6iJJUH76d8p39lX+SyTAsTDc+6TJeorJpcKGB5b cgPO58GWumu6rLv7lAasjCI0c0hGjKTX3htIJwy0= References: <87y4hmi19i.fsf@vigenere.g10code.de> Mime-Version: 1.0 (1.0) In-Reply-To: <87y4hmi19i.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> X-Mailer: iPhone Mail (13A4325c) From: Paul Wouters Date: Sat, 8 Aug 2015 14:43:19 +0200 To: Werner Koch Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 12:43:29 -0000 What is the rationale to implement all sha3 variants? I understand some protocols need lower grade versions for performance reason= s but that seems to matter a lot less for openpgp usage. Why not just implem= ent sha3-512? Sent from my iPhone > On Aug 8, 2015, at 11:21, Werner Koch wrote: >=20 > Hi! >=20 > Now that an official SHA3 specs has been published I would like to see > algorithm ids assigned. Although it is some time until we can publish > rfc-4880bis, it would be useful to agree on the algorithm ids now. > This would be helpful for experimental implementations. Thus what about > this new table with the SHA2 drop in replacements: >=20 > ID Algorithm Text Name > -- --------- --------- > 1 - MD5 [HAC] "MD5" > 2 - SHA-1 [FIPS180] "SHA1" > 3 - RIPE-MD/160 [HAC] "RIPEMD160" > 4 - Reserved > 5 - Reserved > 6 - Reserved > 7 - Reserved > 8 - SHA256 [FIPS180] "SHA256" > 9 - SHA384 [FIPS180] "SHA384" > 10 - SHA512 [FIPS180] "SHA512" > 11 - SHA224 [FIPS180] "SHA224" > 12 - SHA3-224 [FIPS202] "SHA3-224" > 13 - SHA3-256 [FIPS202] "SHA3-256" > 14 - SHA3-384 [FIPS202] "SHA3-384" > 15 - SHA3-512 [FIPS202] "SHA3-512" > 100 to 110 - Private/Experimental algorithm >=20 > Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224 > and thus it ended up out of order. >=20 > I am not sure about the text name. Is a dash okay (cf. armor header)? >=20 > The OIDS are: >=20 > The hexadecimal representations for the > currently defined hash algorithms are as follows: >=20 > [...] =20 >=20 > - SHA3-224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07 > - SHA3-256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08 > - SHA3-384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x09 > - SHA3-512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a >=20 > The ASN.1 Object Identifiers (OIDs) are as follows: >=20 > [...] >=20 > - SHA3-224: 2.16.840.1.101.3.4.2.7 > - SHA3-256: 2.16.840.1.101.3.4.2.8 > - SHA3-384: 2.16.840.1.101.3.4.2.9 > - SHA3-512: 2.16.840.1.101.3.4.2.10 >=20 > The full hash prefixes for these are as follows: >=20 > [...] >=20 > SHA3-224: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 >=20 > SHA3-256: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 >=20 > SHA3-384: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 >=20 > SHA3-512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 >=20 >=20 >=20 > Shalom-Salam, >=20 > Werner >=20 >=20 > --=20 > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sat Aug 8 06:48:43 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2E1ACD81 for ; Sat, 8 Aug 2015 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 lEhwS8cqa0gy for ; Sat, 8 Aug 2015 06:48:32 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (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 28EE91ACD7C for ; Sat, 8 Aug 2015 06:48:32 -0700 (PDT) Received: by labjt7 with SMTP id jt7so63199306lab.0 for ; Sat, 08 Aug 2015 06:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=PZx6hVzZyu1D6ZMKB9+mYfOlhZjc/8frmF+M3Z3lucM=; b=sPv6v3ndBZKJAUGrZOM15KiF6etFcHrqtRERiHu4NbcZ478uAh1Df6Id9FKCkIdW1g ZKMUCVnOCSFAJzOlZxzPjejp5G6sX+eTExmq8OJWXCo8SsR+wZckxC3cMN7xxL/754CH YcYOQOwdDObvOTpnCiJNCJzlnn2xV9ZdjdltJJXuVN4FGDYTm0AwF35relF3but2V2EF FoWZ65558Ype3LNllBdUtLgt+BzUsgWPePWCdNFoW6Fb7Ka2lYg3I0I9x9YCAu2A1C1b d/tFSu1j6hjfhhsLnReU7u6hNwB5S2xNOeDNo9++0KUyHJqFlCUBO1fC01Gqy6rIEwZg zcdw== MIME-Version: 1.0 X-Received: by 10.152.2.2 with SMTP id 2mr13140396laq.58.1439041710603; Sat, 08 Aug 2015 06:48:30 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 8 Aug 2015 06:48:30 -0700 (PDT) In-Reply-To: <87y4hmi19i.fsf@vigenere.g10code.de> References: <87y4hmi19i.fsf@vigenere.g10code.de> Date: Sat, 8 Aug 2015 09:48:30 -0400 X-Google-Sender-Auth: oGWLVNKNv5wYoG4qGeYi_TV_GgA Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=089e013c6470fa4427051ccd010d Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 13:48:35 -0000 --089e013c6470fa4427051ccd010d Content-Type: text/plain; charset=UTF-8 This is an IANA maintained registry so IANA picks the code points while they are in charge. But what is sometimes done when there is a working group working on a protocol with a lot of code points, the registry is moved out of IANA control and someone in the WG manages it. This is the way PKIX worked. It is also possible that the way to do this would be for a single document to propose code points for all the active crypto specs. On Sat, Aug 8, 2015 at 5:21 AM, Werner Koch wrote: > Hi! > > Now that an official SHA3 specs has been published I would like to see > algorithm ids assigned. Although it is some time until we can publish > rfc-4880bis, it would be useful to agree on the algorithm ids now. > This would be helpful for experimental implementations. Thus what about > this new table with the SHA2 drop in replacements: > > ID Algorithm Text Name > -- --------- --------- > 1 - MD5 [HAC] "MD5" > 2 - SHA-1 [FIPS180] "SHA1" > 3 - RIPE-MD/160 [HAC] "RIPEMD160" > 4 - Reserved > 5 - Reserved > 6 - Reserved > 7 - Reserved > 8 - SHA256 [FIPS180] "SHA256" > 9 - SHA384 [FIPS180] "SHA384" > 10 - SHA512 [FIPS180] "SHA512" > 11 - SHA224 [FIPS180] "SHA224" > 12 - SHA3-224 [FIPS202] "SHA3-224" > 13 - SHA3-256 [FIPS202] "SHA3-256" > 14 - SHA3-384 [FIPS202] "SHA3-384" > 15 - SHA3-512 [FIPS202] "SHA3-512" > 100 to 110 - Private/Experimental algorithm > > Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224 > and thus it ended up out of order. > > I am not sure about the text name. Is a dash okay (cf. armor header)? > > The OIDS are: > > The hexadecimal representations for the > currently defined hash algorithms are as follows: > > [...] > > - SHA3-224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07 > - SHA3-256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08 > - SHA3-384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x09 > - SHA3-512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a > > The ASN.1 Object Identifiers (OIDs) are as follows: > > [...] > > - SHA3-224: 2.16.840.1.101.3.4.2.7 > - SHA3-256: 2.16.840.1.101.3.4.2.8 > - SHA3-384: 2.16.840.1.101.3.4.2.9 > - SHA3-512: 2.16.840.1.101.3.4.2.10 > > The full hash prefixes for these are as follows: > > [...] > > SHA3-224: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > SHA3-256: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > SHA3-384: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > SHA3-512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --089e013c6470fa4427051ccd010d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is an IANA maintained registry so IANA picks the code= points while they are in charge.

But what is sometimes = done when there is a working group working on a protocol with a lot of code= points, the registry is moved out of IANA control and someone in the WG ma= nages it. This is the way PKIX worked.

It is also = possible that the way to do this would be for a single document to propose = code points for all the active crypto specs.


<= /div>

On Sat= , Aug 8, 2015 at 5:21 AM, Werner Koch <wk@gnupg.org> wrote:
Hi!

Now that an official SHA3 specs has been published I would like to see
algorithm ids assigned.=C2=A0 Although it is some time until we can publish=
rfc-4880bis, it would be useful to agree on the algorithm ids now.
This would be helpful for experimental implementations.=C2=A0 Thus what abo= ut
this new table with the SHA2 drop in replacements:

=C2=A0 =C2=A0 =C2=A0 ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Algorithm= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Text Name
=C2=A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------
=C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - MD5 [HAC]=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"MD5"
=C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - SHA-1 [FIPS180]= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"SHA1"
=C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - RIPE-MD/160 [HAC= ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"RIPEMD160"
=C2=A0 =C2=A0 =C2=A0 4=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Reserved
=C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Reserved
=C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Reserved
=C2=A0 =C2=A0 =C2=A0 7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Reserved
=C2=A0 =C2=A0 =C2=A0 8=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - SHA256 [FIPS180]= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "SHA256"
=C2=A0 =C2=A0 =C2=A0 9=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - SHA384 [FIPS180]= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "SHA384"
=C2=A0 =C2=A0 =C2=A0 10=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA512 [FIPS180]= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "SHA512"
=C2=A0 =C2=A0 =C2=A0 11=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA224 [FIPS180]= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "SHA224"
=C2=A0 =C2=A0 =C2=A0 12=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA3-224 [FIPS20= 2]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;SHA3-224"
=C2=A0 =C2=A0 =C2=A0 13=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA3-256 [FIPS20= 2]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;SHA3-256"
=C2=A0 =C2=A0 =C2=A0 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA3-384 [FIPS20= 2]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;SHA3-384"
=C2=A0 =C2=A0 =C2=A0 15=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA3-512 [FIPS20= 2]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;SHA3-512"
=C2=A0 =C2=A0 =C2=A0 100 to 110 - Private/Experimental algorithm

Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224 and thus it ended up out of order.

I am not sure about the text name.=C2=A0 Is a dash okay (cf. armor header)?=

The OIDS are:

=C2=A0 =C2=A0The hexadecimal representations for the
=C2=A0 =C2=A0currently defined hash algorithms are as follows:

=C2=A0 =C2=A0 =C2=A0[...]

=C2=A0 =C2=A0 =C2=A0- SHA3-224:=C2=A0 =C2=A00x60, 0x86, 0x48, 0x01, 0x65, 0= x03, 0x04, 0x02, 0x07
=C2=A0 =C2=A0 =C2=A0- SHA3-256:=C2=A0 =C2=A00x60, 0x86, 0x48, 0x01, 0x65, 0= x03, 0x04, 0x02, 0x08
=C2=A0 =C2=A0 =C2=A0- SHA3-384:=C2=A0 =C2=A00x60, 0x86, 0x48, 0x01, 0x65, 0= x03, 0x04, 0x02, 0x09
=C2=A0 =C2=A0 =C2=A0- SHA3-512:=C2=A0 =C2=A00x60, 0x86, 0x48, 0x01, 0x65, 0= x03, 0x04, 0x02, 0x0a

=C2=A0 =C2=A0The ASN.1 Object Identifiers (OIDs) are as follows:

=C2=A0 =C2=A0 =C2=A0[...]

=C2=A0 =C2=A0 =C2=A0- SHA3-224:=C2=A0 =C2=A02.16.840.1.101.3.4.2.7
=C2=A0 =C2=A0 =C2=A0- SHA3-256:=C2=A0 =C2=A02.16.840.1.101.3.4.2.8
=C2=A0 =C2=A0 =C2=A0- SHA3-384:=C2=A0 =C2=A02.16.840.1.101.3.4.2.9
=C2=A0 =C2=A0 =C2=A0- SHA3-512:=C2=A0 =C2=A02.16.840.1.101.3.4.2.10

=C2=A0 =C2=A0The full hash prefixes for these are as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]

=C2=A0 =C2=A0 =C2=A0 =C2=A0SHA3-224:=C2=A0 =C2=A00x30, 0x51, 0x30, 0x0d, 0x= 06, 0x09, 0x60, 0x86,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x48, = 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00, = 0x04, 0x40

=C2=A0 =C2=A0 =C2=A0 =C2=A0SHA3-256:=C2=A0 =C2=A00x30, 0x51, 0x30, 0x0d, 0x= 06, 0x09, 0x60, 0x86,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x48, = 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00, = 0x04, 0x40

=C2=A0 =C2=A0 =C2=A0 =C2=A0SHA3-384:=C2=A0 =C2=A00x30, 0x51, 0x30, 0x0d, 0x= 06, 0x09, 0x60, 0x86,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x48, = 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00, = 0x04, 0x40

=C2=A0 =C2=A0 =C2=A0 =C2=A0SHA3-512:=C2=A0 =C2=A00x30, 0x51, 0x30, 0x0d, 0x= 06, 0x09, 0x60, 0x86,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x48, = 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00, = 0x04, 0x40



Shalom-Salam,

=C2=A0 =C2=A0Werner


--
Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--089e013c6470fa4427051ccd010d-- From nobody Sat Aug 8 15:25:52 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF931A00DB for ; Sat, 8 Aug 2015 15:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 y-owGXP8Bhq4 for ; Sat, 8 Aug 2015 15:25:50 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3011A00BF for ; Sat, 8 Aug 2015 15:25:50 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 4BC306D723; Sat, 8 Aug 2015 18:25:49 -0400 (EDT) Message-ID: <55C681FC.9010100@iang.org> Date: Sat, 08 Aug 2015 23:26:04 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> In-Reply-To: <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 22:25:52 -0000 On 8/08/2015 13:43 pm, Paul Wouters wrote: > What is the rationale to implement all sha3 variants? I agree, I'd like to see a really good rationale. > I understand some protocols need lower grade versions for performance reasons but that seems to matter a lot less for openpgp usage. Why not just implement sha3-512? One would be good. Suits me to go for the longest one. How about this: >> ID Algorithm Text Name >> -- --------- --------- snip >> 12 - RESERVED >> 13 - RESERVED >> 14 - RESERVED >> 15 - SHA3-512 [FIPS202] "SHA3-512" And while we're at it, can we add DEPRECATED to all the rest except SHA(2)512 ? iang ps; And that 100-110 monstrosity - sheesh! ;-) From nobody Sat Aug 8 15:35:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FF11A1A7F for ; Sat, 8 Aug 2015 15:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 i21C3J4dtflB for ; Sat, 8 Aug 2015 15:35:27 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 0FFBB1A1A15 for ; Sat, 8 Aug 2015 15:35:27 -0700 (PDT) Received: by lagz9 with SMTP id z9so38311233lag.3 for ; Sat, 08 Aug 2015 15:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3E3/fzTGdbjYT7cGErJ8jyLJLo7mpSnpvBIKjkYZ6L4=; b=CN6WABfdN/IoNh3k89LTExzgLgb5CnNpfFdNOVd+k4nH0vR65AFCzAuYUg0iX7HmkY +gJK0/irGNLALTQ/xdqr22IZgdJyBp1wZgXLvtE6kJEidYJ7hrG5kLMxxjaqo0Z5wVvg yqJmdS5GYay/xnJ5HBrA3P2J0ChMYlrKfroz8Zcm65Dll6wsYab1fORqQW5tnV67zh+T +C4Hy/lwbNA/rBowdYMlDlpEHAqr0167aEDBd2tSv+ujNThuim5KZSvd6//UiYI3bYZp qefs52OPA8KD9isWyVsWdqeI1EF40QFErJ4Yhm+vbiFUBLhXgJ2+A366elr4shK/BePi zzJQ== MIME-Version: 1.0 X-Received: by 10.112.12.233 with SMTP id b9mr14067411lbc.91.1439073325551; Sat, 08 Aug 2015 15:35:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 8 Aug 2015 15:35:25 -0700 (PDT) In-Reply-To: <55C681FC.9010100@iang.org> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> Date: Sat, 8 Aug 2015 18:35:25 -0400 X-Google-Sender-Auth: iuu4UF41o0l4v5WO4x-q15rHdHU Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: multipart/alternative; boundary=001a11c3b9de601832051cd45e10 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 22:35:28 -0000 --001a11c3b9de601832051cd45e10 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 8, 2015 at 6:26 PM, ianG wrote: > On 8/08/2015 13:43 pm, Paul Wouters wrote: > >> What is the rationale to implement all sha3 variants? >> > > I agree, I'd like to see a really good rationale. > > I understand some protocols need lower grade versions for performance >> reasons but that seems to matter a lot less for openpgp usage. Why not just >> implement sha3-512? >> > > One would be good. Suits me to go for the longest one. > > How about this: > > > > ID Algorithm Text Name >>> -- --------- --------- >>> >> > snip > > 12 - RESERVED >>> 13 - RESERVED >>> 14 - RESERVED >>> 15 - SHA3-512 [FIPS202] "SHA3-512" >>> >> > > > And while we're at it, can we add DEPRECATED to all the rest except > SHA(2)512 ? Discussion in CFRG was definitely pointing to using 512 for the hash required for the internal bit. So if we choose one it should be 512 and truncate where necessary in the UI part. --001a11c3b9de601832051cd45e10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 8, 2015 at 6:26 PM, ianG <iang@iang.org> wrote:<= br>
On 8/08/2015 13:43 pm, P= aul Wouters wrote:
What is the rationale to implement all sha3 variants?

 I agree, I'd like to see a really good rationale.

I understand some protocols need lower grade versions for performance reaso= ns but that seems to matter a lot less for openpgp usage. Why not just impl= ement sha3-512?

 One would be good.=C2=A0 Suits me to go for the longest one.

How about this:



=C2=A0 =C2=A0 =C2=A0 ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Algorithm= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Text Name
=C2=A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------

 snip

=C2=A0 =C2=A0 =C2=A0 12=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- RESERVED
=C2=A0 =C2=A0 =C2=A0 13=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- RESERVED
=C2=A0 =C2=A0 =C2=A0 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- RESERVED
=C2=A0 =C2=A0 =C2=A0 15=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- SHA3-512 [FIPS20= 2]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;SHA3-512"



And while we're at it, can we add DEPRECATED to all the rest except SHA= (2)512 ?

Discussion in CFRG was definitely = pointing to using 512 for the hash required for the internal bit. So if we = choose one it should be 512 and truncate where necessary in the UI part.
=C2=A0
--001a11c3b9de601832051cd45e10-- From nobody Sat Aug 8 15:47:58 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5121B2C65 for ; Sat, 8 Aug 2015 15:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 LaQlpmYFvAdc for ; Sat, 8 Aug 2015 15:47:55 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124B81B2C64 for ; Sat, 8 Aug 2015 15:47:55 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 15D186D72C; Sat, 8 Aug 2015 18:47:53 -0400 (EDT) Message-ID: <55C68729.3050603@iang.org> Date: Sat, 08 Aug 2015 23:48:09 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <835832901.20150808225230@gmail.com> In-Reply-To: <835832901.20150808225230@gmail.com> X-Forwarded-Message-Id: <835832901.20150808225230@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 22:47:57 -0000 On 8/08/2015 23:35 pm, Phillip Hallam-Baker wrote:> > Discussion in CFRG was definitely > pointing to using 512 for the hash > required for the internal bit. > So if we choose one it should be 512 and > truncate where necessary in the UI part. My "position" is only one hash, as many know well. I prefer the longest, because they are computers and they don't have enough work to do. However, I really don't care which one that much. Note this by http://www.metzdowd.com/pipermail/cryptography/2015-August/026238.html (ftr, I don't follow it as yet) iang -------- Forwarded Message -------- Subject: Re: [Cryptography] SHA-3 FIPS-202: no SHAKE512 but SHAKE128; confusing SHAKE security Date: Sat, 8 Aug 2015 22:52:30 +0200 From: Krisztián Pintér To: cryptography@metzdowd.com Michal Bozon (at Saturday, August 8, 2015, 12:59:07 PM): > I was just wondering why the Keccak capacity for best extendable output > hash function was not chosen to be at least as big as for the best fixed > hash function. the reason for the SHAKE's is exactly to have something reasonable, unlike the SHA3 instances, which are not. as it happened, the keccak team submitted stupid parameters, because the NIST call for submissions was unclear, and they didn't want to be disqualified. old hash functions often have larger security against preimage attacks than collision attacks. NIST wanted something that has at least the same security as the SHA2 variants. so the keccak team had to replicate the 256 bit preimage and 128 collision for the SHA-256 drop-in. that requires 512 bit capacity. it is especially crazy for the SHA3-512 version, which now has 512 bit preimage security, which is for all intents and purposes a nonsensical securit level. this comes at a terrible performance hit. it is completely useless. you want one general security against everything. therefore NIST proposed to change the parametrization to have 256bit output, 256 bit capacity for the SHA3-256. that would have a general 128 bit security. this was in agreement with the keccak team's intent. they actually discussed it, and agreed to it. this is how you use keccak if you are a sane person. here comes the crypto celebrity mob. schneier and the like were quick to jump on the "NIST weakens crypto again" bandwagon. the entire thing was shameful. to save its nonexistent reputation, NIST backed off, and decided to standardize the original stupid parameters. congrats to everyone involved, djb included! so to save the day, they added the SHAKE instances as a workaround. they are pretty much what SHA3 should have been. if you don't understand how a sponge works, you are very much free to use the SHA3 instances. but if you want to do actual cryptography, you should choose the SHAKE's. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography From nobody Sat Aug 8 16:17:20 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AFB1A87B0 for ; Sat, 8 Aug 2015 16:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 pamJXj6dBQ4T for ; Sat, 8 Aug 2015 16:17:17 -0700 (PDT) Received: from mailgw-01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A29B1A8726 for ; Sat, 8 Aug 2015 16:17:17 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw-01.dd24.net (Postfix) with ESMTP id EE6575FB96 for ; Sat, 8 Aug 2015 23:17:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw-01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id t-NR7Ecwye0z for ; Sat, 8 Aug 2015 23:17:13 +0000 (UTC) Received: from heisenberg.scientia.net (p579DF309.dip0.t-ipconnect.de [87.157.243.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw-01.dd24.net (Postfix) with ESMTPSA for ; Sat, 8 Aug 2015 23:17:13 +0000 (UTC) Message-ID: <1439075830.20521.66.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Sun, 09 Aug 2015 01:17:10 +0200 In-Reply-To: <55C68729.3050603@iang.org> References: <835832901.20150808225230@gmail.com> <55C68729.3050603@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-UcrEuDSmCW66e/ia5xc+" X-Mailer: Evolution 3.16.3-1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 23:17:19 -0000 --=-UcrEuDSmCW66e/ia5xc+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2015-08-08 at 23:48 +0100, ianG wrote: > My "position" is only one hash, as many know well. I prefer the > longest, because they are computers and they don't have enough work=20 > to=20 > do. If only one is to be assigned a number, it should be definitely the longest. Cheers, Chris. --=-UcrEuDSmCW66e/ia5xc+ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgwODIzMTcx MFowTwYJKoZIhvcNAQkEMUIEQLyBIzafq1SJHgoA23S4l5X2E5eUiIxqz4q9lQPPo+uLAmHuPs0n gh77z2qfTIVlwJCL3IN/mYIl5iDSNA/9nZwwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAnnDn6vDBf3wyH7diJ1AV7w7xEMcF2 u8eFz4HSaVWfRM4F/Animm3TJ0txB8HqaAzr5i37DrNtBOJfvy0xjTya5th+nNJqLVJ8nidC4INe A/4eVrHPDAvk14U8hciaxryHveHqXZwBBAYi/NJAd67fIEqvZ3sdNPUverUltKAfPXhXJwT9EmZa CbT6X9HApoxMhhjoauuG1e890HEaAsnyIB7vK53mPdWVYmqBF6WSpT3+ayNF650JhmDN3DxG+0Oh PHNhg/vIVn6cO/EyHjDSkU1FLJO/VPAeD/B3VBxvrWNIMvss5abUTdLgLRRaYTGQl07pWjb7dHEv g+b5Xg96AAAAAAAA --=-UcrEuDSmCW66e/ia5xc+-- From nobody Sat Aug 8 18:40:57 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02C21A8A7B for ; Sat, 8 Aug 2015 18:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 75k-QswyVS9E for ; Sat, 8 Aug 2015 18:40:54 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (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 C92A61A1AB2 for ; Sat, 8 Aug 2015 18:40:53 -0700 (PDT) Received: by labd1 with SMTP id d1so25302304lab.1 for ; Sat, 08 Aug 2015 18:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=D8k1123quOmtpKys0nwZQTBVL7vZ6VfbL2ZExxkKvVU=; b=Ue5g4NArQeImCM8rFUXwOOTnPCQLi06M6jWh2oBc7oxD4845Z+QVDKkcfhjpHLpB39 h54laTABCnwz1HtU56u7bIcqUEjwW3b07gVSVwLYSZ7oaM8qTlBu4J6nNA7yElhe+eZM 244KWOcPrrMNEbC7j1Qa6bp1IbsoauOX1xftv9E8otqtqfnDwq49L+1qFrc4e/hNl1Wo 48X3Qk4knRUHZeWl9kB45bsJOuaDdZ9cHXoHKIYZTpT4t9NbLa1Pl4BuUuUTKndblLwu Leo5ZRVnqZhMvWo2b8BEPzTPqQnUiMBUTW0nPPMZ4Okopg/JXSFhETgmxibqy4bDp18M 2T4g== MIME-Version: 1.0 X-Received: by 10.152.204.196 with SMTP id la4mr14881683lac.124.1439084452013; Sat, 08 Aug 2015 18:40:52 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 8 Aug 2015 18:40:51 -0700 (PDT) In-Reply-To: <1439075830.20521.66.camel@scientia.net> References: <835832901.20150808225230@gmail.com> <55C68729.3050603@iang.org> <1439075830.20521.66.camel@scientia.net> Date: Sat, 8 Aug 2015 21:40:51 -0400 X-Google-Sender-Auth: MAHOPLu_tizKexGJyofTP7oLgN4 Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: multipart/alternative; boundary=001a113499ce906d13051cd6f5c2 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 01:40:55 -0000 --001a113499ce906d13051cd6f5c2 Content-Type: text/plain; charset=UTF-8 Thinking this through a bit further. Why is anyone going to move from SHA-2 to SHA-3 ? Only reason I can think of is a real or perceived weakness in SHA-2. That being so, I can't see why they would go for a lower number of bits/rounds. For OpenPGP, I think the case for 512 only or 256 and 512 is pretty strong. On Sat, Aug 8, 2015 at 7:17 PM, Christoph Anton Mitterer < calestyo@scientia.net> wrote: > On Sat, 2015-08-08 at 23:48 +0100, ianG wrote: > > My "position" is only one hash, as many know well. I prefer the > > longest, because they are computers and they don't have enough work > > to > > do. > If only one is to be assigned a number, it should be definitely the > longest. > > Cheers, > Chris. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > --001a113499ce906d13051cd6f5c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thinking this through a bit further.

Wh= y is anyone going to move from SHA-2 to SHA-3 ? Only reason I can think of = is a real or perceived weakness in SHA-2.=C2=A0

Th= at being so, I can't see why they would go for a lower number of bits/r= ounds.

For OpenPGP, I think the case for 512 only = or 256 and 512 is pretty strong.=C2=A0


On Sat, Aug 8, 2015 at 7:17= PM, Christoph Anton Mitterer <calestyo@scientia.net> wr= ote:
On Sat, 2015-08-08 = at 23:48 +0100, ianG wrote:
> My "position" is only one hash, as many know well.=C2=A0 I p= refer the
> longest, because they are computers and they don't have enough wor= k
> to
> do.
If only one is to be assigned a number, it should be definitely the<= br> longest.

Cheers,
Chris.
_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp


--001a113499ce906d13051cd6f5c2-- From nobody Sat Aug 8 20:22:12 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD81A7034 for ; Sat, 8 Aug 2015 20:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HypQHjalZZxQ for ; Sat, 8 Aug 2015 20:22:09 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3D21A21B7 for ; Sat, 8 Aug 2015 20:22:09 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D5C7A6D73B; Sat, 8 Aug 2015 23:22:07 -0400 (EDT) Message-ID: <55C6C76F.3010502@iang.org> Date: Sun, 09 Aug 2015 04:22:23 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <835832901.20150808225230@gmail.com> <55C68729.3050603@iang.org> <1439075830.20521.66.camel@scientia.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 03:22:10 -0000 On 9/08/2015 02:40 am, Phillip Hallam-Baker wrote: > Thinking this through a bit further. > > Why is anyone going to move from SHA-2 to SHA-3 ? Only reason I can > think of is a real or perceived weakness in SHA-2. For which they ran a competition :) OK so now thinking has changed a bit. "It's not pressing." But it's always worth going for the most recent work; the thinking is that SHA2 is not broken, which isn't the same as "it's state of the art." SHA2 is cerca late 1990s design. SHA3 is early 2010s. I'm guessing that difference is worth another 15 years on the lifespan. My other reason for going for SHA3 is that then we could potentially do the one-symmetric-suite on one code base, as one obligatory set. However, that's only a thought balloon. I've not looked at the complexity of SHA3 as hash or as AE algorithm (Keyak), in code. It could be that the total coding complexity of say SHA2 + Chacha/Poly is less than the new set, even with the same base. As a coder, this is 99% of the worry - how complicated is the code, or worse, as a manager, how much do I have to pay someone to implement it? > That being so, I can't see why they would go for a lower number of > bits/rounds. Only reason could be that discussion of SHAKEs versus SHAs, and some artifact that indicated that the longest rounds were actually inefficient and over the top. > For OpenPGP, I think the case for 512 only or 256 and 512 is pretty strong. > > > On Sat, Aug 8, 2015 at 7:17 PM, Christoph Anton Mitterer > > wrote: > > On Sat, 2015-08-08 at 23:48 +0100, ianG wrote: > > My "position" is only one hash, as many know well. I prefer the > > longest, because they are computers and they don't have enough work > > to > > do. > If only one is to be assigned a number, it should be definitely the > longest. > > Cheers, > Chris. From nobody Sun Aug 9 00:55:38 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D111ACDF3 for ; Sun, 9 Aug 2015 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HoPSkDhNV7S7 for ; Sun, 9 Aug 2015 00:55:32 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1101ACDF2 for ; Sun, 9 Aug 2015 00:55:32 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZOLS6-0005p5-7k for ; Sun, 09 Aug 2015 09:55:30 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZOLMv-0002IT-AU; Sun, 09 Aug 2015 09:50:09 +0200 From: Werner Koch To: Paul Wouters References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , openpgp@ietf.org Date: Sun, 09 Aug 2015 09:50:09 +0200 In-Reply-To: <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> (Paul Wouters's message of "Sat, 8 Aug 2015 14:43:19 +0200") Message-ID: <87egjcj3ym.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 07:55:37 -0000 On Sat, 8 Aug 2015 14:43, paul@nohats.ca said: > What is the rationale to implement all sha3 variants? Because they are drop-in replacements for the 4 SHA2 algorithms; that is the whole point of these algorithms. Assigning algorithm ids does not mean that they will be used - that is an entire different story. It is better to have well defined ids than to resort to experimental algorithms. FWIW, I do not plan to support them in write-mode. Although IANA assigns them, we always agreed prior to any official assignment on new algorithm ids. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Aug 9 05:45:07 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CDF1B2C59 for ; Sun, 9 Aug 2015 05:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ToYSbq5ivMJm for ; Sun, 9 Aug 2015 05:45:02 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CED1B2B93 for ; Sun, 9 Aug 2015 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439124302; x=1470660302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2uRQ5wqDqQuzczXJMMadQwPcBqAPueIvhS9SC9UIUSw=; b=KgaecWS2vLtW3PkSjaGmAoDioNeDrb8M2kdr7vUN3BzuVjbWSKchmbhB 13loCTGGYL+RsRJYkNmHIxJf00XtPTVEPRs24wPLsQFVNsS8JJku7FZTP fWHBLDMMRpfImoyLoNZl6j0b5BMYby0m+tvz/Dxog5NgDNdVw23a+d2+t 1z3V95b5yv4FG0dGL2nYpvwWnkllRfjr3Ux01ip218vgEcj6YZVTL+IPC mCJNqIsAsIID+Cor8X8VsZkx1AsmU8h+P2rorJEtp9WBw4jM3mQY/9ehD uvRSweX3j/Ua4NUNziDPk4R8EJbHblJdbzzHHUMWgjuH4h32f9tHXUojT A==; X-IronPort-AV: E=Sophos; i="5.15,639,1432555200"; d="scan'208,217"; a="33896072" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Aug 2015 00:44:59 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Mon, 10 Aug 2015 00:44:59 +1200 From: Peter Gutmann To: Phillip Hallam-Baker , Christoph Anton Mitterer Thread-Topic: [openpgp] SHA3 algorithm ids. Thread-Index: AQHQ0ixIyqqXtSBRvU+ISOnuu2oiTJ4B8zAAgAAoJYCAAYJ3XQ== Date: Sun, 9 Aug 2015 12:44:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD62CC@uxcn10-5.UoA.auckland.ac.nz> References: <835832901.20150808225230@gmail.com> <55C68729.3050603@iang.org> <1439075830.20521.66.camel@scientia.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-originating-ip: [130.216.158.4] Content-Type: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73F4AD62CCuxcn105UoAauckl_" MIME-Version: 1.0 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 12:45:05 -0000 --_000_9A043F3CF02CD34C8E74AC1594475C73F4AD62CCuxcn105UoAauckl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker writes: >Why is anyone going to move from SHA-2 to SHA-3 ? There isn't one. As a result of the SHA-3 competition, we now know that SH= A-2 is a lot stronger than people had originally thought (based on its SHA-1 heritage). So the real winner of the SHA-3 competition was SHA-2. >For OpenPGP, I think the case for 512 only or 256 and 512 is pretty strong= . The case for -256 only is that it's no worse than -512 but half the size. This is particularly egregious for things like TLS and SSH, where you have = to use an idiotic-length 64-byte MAC if you want to protect a single-byte keystroke. It's less so for PGP and S/MIME where you're not sending a constant stream of packets all unnecessarily bloated up by 64 bytes, but it= 's still pointless. Peter. --_000_9A043F3CF02CD34C8E74AC1594475C73F4AD62CCuxcn105UoAauckl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Phillip Hallam-Baker <phill@hallambaker.com> writes:

>Why is anyone going to move fr= om SHA-2 to SHA-3 ?

There isn't one.  As a result of the SHA-3 competition, we now know th= at SHA-2
is a lot stronger than people had originally thought (based on its SHA-1 heritage).  So the real winner of the SHA-3 competition was SHA-2.

>For OpenPGP, I think the case for 512 only or 256 and 512 is pretty str= ong.

The case for -256 only is that it's no worse than -512 but half the size. This is particularly egregious for things like TLS and SSH, where you have = to
use an idiotic-length 64-byte MAC if you want to protect a single-byte
keystroke.  It's less so for PGP and S/MIME where you're not sending a=
constant stream of packets all unnecessarily bloated up by 64 bytes, but it= 's
still pointless.

Peter.

--_000_9A043F3CF02CD34C8E74AC1594475C73F4AD62CCuxcn105UoAauckl_-- From nobody Sun Aug 9 06:09:25 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CBB1B2CC3 for ; Sun, 9 Aug 2015 06:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 LB3BTdnMKdUZ for ; Sun, 9 Aug 2015 06:09:22 -0700 (PDT) Received: from mailgw-01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349091B2CC5 for ; Sun, 9 Aug 2015 06:09:22 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw-01.dd24.net (Postfix) with ESMTP id DCF995FAD9 for ; Sun, 9 Aug 2015 13:09:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw-01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id mRyUGJ4UWRix for ; Sun, 9 Aug 2015 13:09:18 +0000 (UTC) Received: from heisenberg.scientia.net (p5B1000BE.dip0.t-ipconnect.de [91.16.0.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw-01.dd24.net (Postfix) with ESMTPSA for ; Sun, 9 Aug 2015 13:09:18 +0000 (UTC) Message-ID: <1439090997.20521.108.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP In-Reply-To: References: <835832901.20150808225230@gmail.com> <55C68729.3050603@iang.org> <1439075830.20521.66.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-QPRmndcx5j+UTa/zFMu6" Date: Sun, 09 Aug 2015 05:29:57 +0200 Mime-Version: 1.0 X-Mailer: Evolution 3.16.3-1 Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 13:09:24 -0000 --=-QPRmndcx5j+UTa/zFMu6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2015-08-08 at 21:40 -0400, Phillip Hallam-Baker wrote: > Why is anyone going to move from SHA-2 to SHA-3 ? Only reason I can > think of is a real or perceived weakness in SHA-2. Or for reasons of diversity (and the advantages thereof), which may again make the non-512(/256) versions of SHA-3) interesting for some people. Cheers, Chris. --=-QPRmndcx5j+UTa/zFMu6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgwOTAzMjk1 N1owTwYJKoZIhvcNAQkEMUIEQJ6QrLDBfVI+uOwCwTcb9HndhSndNhr6eh8E9C21MDDhwQPGO3PE 1Pe952JtSQTB8jPEB0qd3hq+dzaErQRUtHswagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQC27i5MbimyjPy0Ij6miiwDNrwYKDy4 uGZzTJuJ8YeOKSza3OOrhLg42MmcdoyQh90R7DLII1BLWJD/+l9kk7ZcH/pYB0O3QrHAt4Z7apWs E3+w86AHiXMD5zzadqwUInZWEmH3JzDK1z+EX666XRTC51xs0LNVgGUACK+rL7WN6SqGzcb95m7X gmnirFkh/PE/Nr6XOsztJ+D3mA//iPS/IujnsTV/N2xOugTIhZDN00Ej0AsA/OMkXA7f7Rhwx3+m 6oiempVJOLR2X5GAugDN3snyjMXTYFwzM9ErOX7+E1BiRrSl5p57G12d2ZeCCdf2wYEiK6AKpFwI hj9scNSiAAAAAAAA --=-QPRmndcx5j+UTa/zFMu6-- From nobody Sun Aug 9 08:49:21 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502861ACDFD for ; Sun, 9 Aug 2015 08:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 KZOE49ziCItS for ; Sun, 9 Aug 2015 08:49:19 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 07E1A1ACDF8 for ; Sun, 9 Aug 2015 08:49:18 -0700 (PDT) Received: from [174.236.2.168] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZOSqW-0001AT-Bh for openpgp@ietf.org; Sun, 09 Aug 2015 11:49:13 -0400 Date: Sun, 9 Aug 2015 08:49:40 -0700 From: Bill Frantz To: openpgp@ietf.org X-Priority: 3 In-Reply-To: <878u9n76py.fsf@littlepip.fritz.box> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79221265d599af1e0d5ecfa15e5071d7ba350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.236.2.168 Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 15:49:20 -0000 I am more and more convinced of the wisdom of Alan Karp when he=20 insists that any system which uses a hash must specify what=20 happens when there is a hash collision. He points out that=20 anytime data longer than the hash output is hashed, there is the=20 possibility of a collision, which is true when calculating key fingerprints= . Now the consequences may be severe or trivial. If a PGP message=20 routing application uses the fingerprint to select the=20 destination, the consequence of a collision may be as trivial as=20 routing messages to recipients who can't decrypt them, or the=20 more serious consequence of not sending messages to the=20 recipient who can decrypt them. The exercise of figuring out=20 what will happen results in better design. There has also been an undertone of, "If we can't come up with=20 an attack, there aren't any." in this thread. I find this=20 attitude very dangerous as new classes of attacks (e.g. power=20 analysis) are constantly being discovered. I would suggest wording in the security considerations section=20 something like: "During the design process, any application using key=20 fingerprints SHOULD characterize the consequences of a=20 fingerprint collision on the application's security and=20 implementation integrity, particularly when using fewer bits=20 than the output of the fingerprint hash." Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Ham radio contesting is a | Periwinkle (408)356-8506 | contact sport. | 16345=20 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos,=20 CA 95032 From nobody Sun Aug 9 09:23:41 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AD21ACF6C for ; Sun, 9 Aug 2015 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 U5PD3CT8QYyq for ; Sun, 9 Aug 2015 09:23:38 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B5E1ACF5B for ; Sun, 9 Aug 2015 09:23:38 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 5E7A46D724; Sun, 9 Aug 2015 12:23:37 -0400 (EDT) Message-ID: <55C77E9B.1080807@iang.org> Date: Sun, 09 Aug 2015 17:23:55 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 16:23:40 -0000 Hi Bill, On 9/08/2015 16:49 pm, Bill Frantz wrote: > I am more and more convinced of the wisdom of Alan Karp when he insists > that any system which uses a hash must specify what happens when there > is a hash collision. He points out that anytime data longer than the > hash output is hashed, there is the possibility of a collision, which is > true when calculating key fingerprints. > > Now the consequences may be severe or trivial. If a PGP message routing > application uses the fingerprint to select the destination, the > consequence of a collision may be as trivial as routing messages to > recipients who can't decrypt them, or the more serious consequence of > not sending messages to the recipient who can decrypt them. The exercise > of figuring out what will happen results in better design. > > > There has also been an undertone of, "If we can't come up with an > attack, there aren't any." in this thread. I disagree with that characterisation. I would rather see it like this: If we can't come up with an attack, then we should not defend against it. We should *accept the risk*. 1. it is likely the attacker won't either. 2. if the attack-space is theoretical or exotic (eg quantum), the likelihood of it developing to a practical attack is low and/or slow. Then, waiting for more info is the smarter thing to do unless there is a cheap easy fix. 3. when an algorithm is designed to be very strong, this gives us an ability to lean on it and rely on it entirely. This delivers benefits in code simplicity, and releases resources to concentrate on what we do know is likely to break, and is hurting our users. The one thing we can say about hashes is they are darn strong. They've never really failed us. The only blackmark was MD5, when some projects where negligent and didn't move [0]. Lean on hashes. 4. how can you defend against an attack you can't come up with? 5. and finally, concentrating on attacks that we imagine might happen in the lab and can't build even a PoC for leads to isolation and myopia. We are in the business of serving our users, and they have plenty of things harming them right now. Let's concentrate on delivering what addresses their pain, not what confuses us. (Although I agree that the risk-analysis methodology -- which explicitly includes the willingness to accept a risk -- has not found widespread favour in our community :) > I find this attitude very > dangerous as new classes of attacks (e.g. power analysis) are constantly > being discovered. 1. when that information develops, we can "come up with the attack." This stops us drifting into lab myopia. 2. How is power analysis going to effect a hash? Surely, if I can do power analysis, I'm not that concerned about the hash, I'd rather suck the key bits? OK, I know it was an example... but this is an example of "not an attack." > I would suggest wording in the security considerations section something > like: > > "During the design process, any application using key fingerprints > SHOULD characterize the consequences of a fingerprint collision on the > application's security and implementation integrity, particularly when > using fewer bits than the output of the fingerprint hash." If we're talking about a mid-range published key fingerprint of say 100 bits, then there is a capability for collisions and perhaps preimages in the future, sure. But we have a built in mechanism for that already; increase to 150 then 200. So how about: "During the design process of any application using shortened key fingerprints, attention should be paid to a recovery strategy in the event that the shortened fingerprint becomes subject to collisions or preimage attacks." And at full hash-length in the fingerprint I'd be silent in the document. Accept the risk. Lean on the full SHAx. It's been the most solid rock in cryptography so far. iang [0] MD5 should have been deprecated in 1993-1995 timescale, SHA1 should have been deprecated in the 2000-2004 timescale, if you are at risk of collision attacks. From nobody Sun Aug 9 14:52:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED72E1A21AF for ; Sun, 9 Aug 2015 14:51:58 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 BXwhwaZXQnn5 for ; Sun, 9 Aug 2015 14:51:57 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 409101A219C for ; Sun, 9 Aug 2015 14:51:56 -0700 (PDT) Received: from [174.236.35.106] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZOYVQ-0006ha-VL; Sun, 09 Aug 2015 17:51:49 -0400 Date: Sun, 9 Aug 2015 14:52:15 -0700 From: Bill Frantz To: ianG X-Priority: 3 In-Reply-To: <55C77E9B.1080807@iang.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec798bfd2f608b3f0690c666301ae546bbc6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.236.35.106 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 21:51:59 -0000 On 8/9/15 at 9:23 AM, iang@iang.org (ianG) wrote: >>There has also been an undertone of, "If we can't come up with an >>attack, there aren't any." in this thread. > > >I disagree with that characterisation. I would rather see it like this: > >If we can't come up with an attack, >then we should not defend against it. >We should *accept the risk*. The specific issue I was addressing was PHB's source code=20 checkin attack. Most of us, me included, thought that specific=20 attack was not very convincing. However, to my mind, there may=20 be other, more serious attacks using the same basic mechanism.=20 Just because we can't think of them doesn't mean we shouldn't=20 defend against them. Using all the bits of the key fingerprint hash is probably good=20 a good enough defense against these unanticipated attacks, and=20 we should state that in the security considerations section. A=20 better defense would be to use the key itself, but that is=20 probably overkill in most situations. >>I find this attitude very >>dangerous as new classes of attacks (e.g. power analysis) are constantly >>being discovered. > > >1. when that information develops, we can "come up with the=20 >attack." This stops us drifting into lab myopia. > >2. How is power analysis going to effect a hash? Surely, if I=20 >can do power analysis, I'm not that concerned about the hash,=20 >I'd rather suck the key bits? OK, I know it was an example...=20 >but this is an example of "not an attack." Power analysis was an example of a class of attack that came up=20 late in the security analysis field and exposed a significant=20 number of vulnerabilities. It is not a attack against hashes.=20 Those are more likely to be new mathematical techniques. >>I would suggest wording in the security considerations section something >>like: >> >>"During the design process, any application using key fingerprints >>SHOULD characterize the consequences of a fingerprint collision on the >>application's security and implementation integrity, particularly when >>using fewer bits than the output of the fingerprint hash." > > >If we're talking about a mid-range published key fingerprint of=20 >say 100 bits, then there is a capability for collisions and=20 >perhaps preimages in the future, sure. > >But we have a built in mechanism for that already; increase to 150 then 2= 00. So how about: > > >"During the design process of any application using shortened=20 >key fingerprints, attention should be paid to a recovery=20 >strategy in the event that the shortened fingerprint becomes=20 >subject to collisions or preimage attacks." My problem with that statement is that there is no incentive to=20 analyse the failure mode of the application should a collision=20 occur. I agree that a collision is far more likely to be due to=20 a hardware or software error than a hash failure, but performing=20 the analysis can make the application more robust. Let me return to my straw man example of a application that=20 routes messages based on key fingerprint. If it assumes that=20 there is only one routing address/fingerprint, and there is a=20 collision, then it will route all the colliding messages to one=20 address. If it assumes that there may be more than one address,=20 then it will route all colliding messages to all the address. In=20 the later case, the receivers will not be able to decrypt all=20 the messages, but the messages encrypted to them will get=20 through, a more robust situation. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Security is like Government | Periwinkle (408)356-8506 | services. The market doesn't | 16345=20 Englewood Ave www.pwpconsult.com | want to pay for them. | Los Gatos,=20 CA 95032 From nobody Sun Aug 9 18:20:26 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ABD1A6F27 for ; Sun, 9 Aug 2015 18:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rljghn_v3IF9 for ; Sun, 9 Aug 2015 18:20:22 -0700 (PDT) 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 505AA1A6F11 for ; Sun, 9 Aug 2015 18:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1188DBE4D; Mon, 10 Aug 2015 02:20:21 +0100 (IST) 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 u3ALARDamUTc; Mon, 10 Aug 2015 02:20:19 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CCCC7BE3E; Mon, 10 Aug 2015 02:20:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439169618; bh=XrTqAf3Qbdg+wa85dV632AZez6M/njOMkWILxBifKDo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jzrzT2hyejGWdsGm9BGOI1VVuGZ2aC5xnNaypxx+hdeg2zJ3CnInetbOsQqSFmG2z SG2La4rkb9knZEssw7smRHVHnbkpJE6WF4fgOoWBvKEMVAuaq2BOAAYceYQ3ul88Gp Qvuo+wzketbMlRlYWh+x5ap1CKS71zz/USiHpGLQ= Message-ID: <55C7FC52.8060904@cs.tcd.ie> Date: Mon, 10 Aug 2015 02:20:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , IETF OpenPGP References: <87y4hmi19i.fsf@vigenere.g10code.de> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 01:20:25 -0000 Just on the process crapology... On 08/08/15 14:48, Phillip Hallam-Baker wrote: > This is an IANA maintained registry so IANA picks the code points while > they are in charge. > > But what is sometimes done when there is a working group working on a > protocol with a lot of code points, the registry is moved out of IANA > control and someone in the WG manages it. This is the way PKIX worked. That's out of date. We've moved those PKIX registries to IANA and Russ no longer manages 'em and more importantly here we've put in place a process for early allocation of IANA code points in RFC 7020. [1] In terms of code points for use of sha-3 in pgp, my reading of 7120 would be that the list will discuss and the chairs will judge if rough consensus has been reached at which point the chairs will have the backing of folks participating in the WG to allocate code points early. Cheers, S. PS: A nice side-effect of using 7120 - IANA regularly send the IESG a summary of the early allocations that will soon expire. That's a great way to kick a WG into finishing a bit of work they ought have gotten done ages before:-) [1] https://tools.ietf.org/html/rfc7120 > > It is also possible that the way to do this would be for a single document > to propose code points for all the active crypto specs. > > > > On Sat, Aug 8, 2015 at 5:21 AM, Werner Koch wrote: > >> Hi! >> >> Now that an official SHA3 specs has been published I would like to see >> algorithm ids assigned. Although it is some time until we can publish >> rfc-4880bis, it would be useful to agree on the algorithm ids now. >> This would be helpful for experimental implementations. Thus what about >> this new table with the SHA2 drop in replacements: >> >> ID Algorithm Text Name >> -- --------- --------- >> 1 - MD5 [HAC] "MD5" >> 2 - SHA-1 [FIPS180] "SHA1" >> 3 - RIPE-MD/160 [HAC] "RIPEMD160" >> 4 - Reserved >> 5 - Reserved >> 6 - Reserved >> 7 - Reserved >> 8 - SHA256 [FIPS180] "SHA256" >> 9 - SHA384 [FIPS180] "SHA384" >> 10 - SHA512 [FIPS180] "SHA512" >> 11 - SHA224 [FIPS180] "SHA224" >> 12 - SHA3-224 [FIPS202] "SHA3-224" >> 13 - SHA3-256 [FIPS202] "SHA3-256" >> 14 - SHA3-384 [FIPS202] "SHA3-384" >> 15 - SHA3-512 [FIPS202] "SHA3-512" >> 100 to 110 - Private/Experimental algorithm >> >> Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224 >> and thus it ended up out of order. >> >> I am not sure about the text name. Is a dash okay (cf. armor header)? >> >> The OIDS are: >> >> The hexadecimal representations for the >> currently defined hash algorithms are as follows: >> >> [...] >> >> - SHA3-224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07 >> - SHA3-256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08 >> - SHA3-384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x09 >> - SHA3-512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a >> >> The ASN.1 Object Identifiers (OIDs) are as follows: >> >> [...] >> >> - SHA3-224: 2.16.840.1.101.3.4.2.7 >> - SHA3-256: 2.16.840.1.101.3.4.2.8 >> - SHA3-384: 2.16.840.1.101.3.4.2.9 >> - SHA3-512: 2.16.840.1.101.3.4.2.10 >> >> The full hash prefixes for these are as follows: >> >> [...] >> >> SHA3-224: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, >> 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, >> 0x00, 0x04, 0x40 >> >> SHA3-256: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, >> 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, >> 0x00, 0x04, 0x40 >> >> SHA3-384: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, >> 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, >> 0x00, 0x04, 0x40 >> >> SHA3-512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, >> 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, >> 0x00, 0x04, 0x40 >> >> >> >> Shalom-Salam, >> >> Werner >> >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Sun Aug 9 20:02:57 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC711A8A94 for ; Sun, 9 Aug 2015 20:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nSn4YJMR8ROs for ; Sun, 9 Aug 2015 20:02:53 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1081A8A91 for ; Sun, 9 Aug 2015 20:02:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id EF0836D72E; Sun, 9 Aug 2015 23:02:51 -0400 (EDT) Message-ID: <55C8146E.1050302@iang.org> Date: Mon, 10 Aug 2015 04:03:10 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <835832901.20150808225230@gmail.com> <55C68729.3050603@iang.org> In-Reply-To: <55C68729.3050603@iang.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 03:02:56 -0000 On 8/08/2015 23:48 pm, ianG wrote: > http://www.metzdowd.com/pipermail/cryptography/2015-August/026238.html > From: Krisztián Pintér ... > so to save the day, they added the SHAKE instances as a workaround. > they are pretty much what SHA3 should have been. if you don't > understand how a sponge works, you are very much free to use the SHA3 > instances. but if you want to do actual cryptography, you should > choose the SHAKE's. Which I think can be interpreted as suggestion to use SHAKE256, instead of the SHA3-xxx. A potential advantage of that is that the algorithm expands, so we don't need to specify truncation any more. Just call it with a range of set params for 'd': keyId: 32 fingerprint: 100, 150 hash: 256. (by way of example) Is there any known advantage of the smaller lengths being subsets of the larger? iang From nobody Mon Aug 10 08:22:38 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D4E1B36D4 for ; Mon, 10 Aug 2015 08:22:37 -0700 (PDT) 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] autolearn=ham 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 fzKkDlz2jM-n for ; Mon, 10 Aug 2015 08:22:36 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143: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 888021B36D0 for ; Mon, 10 Aug 2015 08:22:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 44F94E2036; Mon, 10 Aug 2015 11:22:34 -0400 (EDT) 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 04976-03; Mon, 10 Aug 2015 11:22:32 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 01988E2034; Mon, 10 Aug 2015 11:22:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1439220152; bh=vSlLCXjNV8VfTz6UzClSCl40kYGRZruLwuzAQeJfLE8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=nn6XOo/kaRuqxZ+ICMrWTJqmUHXp76Ge5IqOtOdkIi5tTPi7HqaXujsFHIRLyCbot 3lR8kjMe00niJuwp5JwLyhhTnOl5i+Tq9wEmhmLMt3gRPzZZm9tTQ3oeI2jLEc0ykl 2WOsCCOIFXl2glmVmX101dYqFgQlrqETSSXtlBqU= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7AFMVKJ014339; Mon, 10 Aug 2015 11:22:31 -0400 From: Derek Atkins To: ianG References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> Date: Mon, 10 Aug 2015 11:22:31 -0400 In-Reply-To: <55C681FC.9010100@iang.org> (iang@iang.org's message of "Sat, 08 Aug 2015 23:26:04 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (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] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 15:22:38 -0000 ianG writes: > One would be good. Suits me to go for the longest one. Possibly two... But the SHA3 competition has shown that SHA2 is pretty darn good... > How about this: > > > >>> ID Algorithm Text Name >>> -- --------- --------- > > snip > >>> 12 - RESERVED >>> 13 - RESERVED >>> 14 - RESERVED >>> 15 - SHA3-512 [FIPS202] "SHA3-512" > > > > And while we're at it, can we add DEPRECATED to all the rest except > SHA(2)512 ? I see no reason to deprecate SHA2-256. But I'm fine with all the rest. > iang -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Aug 10 13:50:38 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F081B3E57 for ; Mon, 10 Aug 2015 13:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8GY91ewZddaN for ; Mon, 10 Aug 2015 13:50:35 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 C3E861B3E54 for ; Mon, 10 Aug 2015 13:50:34 -0700 (PDT) Received: by labd1 with SMTP id d1so46724953lab.1 for ; Mon, 10 Aug 2015 13:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wB94GFybf5CQOD44CC7CrOYGuk0h+GK8SmCWL8zuVnA=; b=kVmahdhWXtOWMIDHrSa3Fq3mGWuDe7eQNX/LtDpXAa99TqB0wDhf412fot13aLkAYY mfMREnG7eIO9OzQ22oukh02cG8ix6cNbURlra4p2DgsaL16ez0jwjSTXA2D6sdbJzSOY er0ELq4GyT6tX1oyOSzVxnrlanX4vjSfMWTvaig9ieFd1XeMIgiX07AmEXeQTTEe+eYX +gFg/iQXoSzZZoxa/BxuYylCatq7M/koLpEw6azOIKjoFpFssphcw/v0u4XLbpw3y2mO 7lZtJKDHM9pEYxl31aohXjyFqNeGiDCvxcqAfO/+7488EcGhzo2xj82LbfzZOMiMO2Pu DREA== MIME-Version: 1.0 X-Received: by 10.112.12.233 with SMTP id b9mr21833162lbc.91.1439239832990; Mon, 10 Aug 2015 13:50:32 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 10 Aug 2015 13:50:32 -0700 (PDT) In-Reply-To: References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> Date: Mon, 10 Aug 2015 16:50:32 -0400 X-Google-Sender-Auth: 1wbDkUcKbZ9xeA_-cN4tfuNueag Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c3b9defdfa64051cfb22f8 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:50:37 -0000 --001a11c3b9defdfa64051cfb22f8 Content-Type: text/plain; charset=UTF-8 I agree with Derek (I think). There is a very clear need for 512 bits and there is a case for 256 bits. It does not seem very likely that the other sizes will get use. The competition did result in restoring most people's confidence in SHA-2. It is widely deployed and used today. So I don't see a case for deprecating any of the SHA-2 bit sizes. Right now Comodo and various other CAs are using SHA-2-384 in our ECC certs but that is based on using the NIST curves. It would not surprise me if people using SHA-2 made the same choice. It is quite clear that the CFRG ECC signature scheme will use 512 bit and that is the algorithm most likely to be used with SHA-3. Given that email recipients tend to end up having to implement all the code points in a cipher suite because they can't really control what is sent, I think it is a good plan to be a little parsimonious in selecting key sizes and avoid choosing key strengths that aren't likely to see use. On Mon, Aug 10, 2015 at 11:22 AM, Derek Atkins wrote: > ianG writes: > > > One would be good. Suits me to go for the longest one. > > Possibly two... But the SHA3 competition has shown that SHA2 is pretty > darn good... > > > How about this: > > > > > > > >>> ID Algorithm Text Name > >>> -- --------- --------- > > > > snip > > > >>> 12 - RESERVED > >>> 13 - RESERVED > >>> 14 - RESERVED > >>> 15 - SHA3-512 [FIPS202] "SHA3-512" > > > > > > > > And while we're at it, can we add DEPRECATED to all the rest except > > SHA(2)512 ? > > I see no reason to deprecate SHA2-256. But I'm fine with all the rest. > > > iang > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a11c3b9defdfa64051cfb22f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Derek (I think).

There is = a very clear need for 512 bits and there is a case for 256 bits. It does no= t seem very likely that the other sizes will get use.

<= div>The competition did result in restoring most people's confidence in= SHA-2. It is widely deployed and used today. So I don't see a case for= deprecating any of the SHA-2 bit sizes.=C2=A0

Right now Comodo and various other CAs are using SHA-2-384 in o= ur ECC certs but that is based on using the NIST curves. It would not surpr= ise me if people using SHA-2 made the same choice. It is quite clear that t= he CFRG ECC signature scheme will use 512 bit and that is the algorithm mos= t likely to be used with SHA-3.

Given that email r= ecipients tend to end up having to implement all the code points in a ciphe= r suite because they can't really control what is sent, I think it is a= good plan to be a little parsimonious in selecting key sizes and avoid cho= osing key strengths that aren't likely to see use.

=

On Mon, Aug= 10, 2015 at 11:22 AM, Derek Atkins <derek@ihtfp.com> wrote:
ianG <iang@iang.org> writes:

> One would be good.=C2=A0 Suits me to go for the longest one.

Possibly two...=C2=A0 But the SHA3 competition has shown that SHA2 i= s pretty
darn good...

> How about this:
>
>
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Algorithm=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Text Name
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0---------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------
>
> snip
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A012=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= - RESERVED
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A013=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= - RESERVED
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A014=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= - RESERVED
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= - SHA3-512 [FIPS202]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 "SHA3-512"
>
>
>
> And while we're at it, can we add DEPRECATED to all the rest excep= t
> SHA(2)512 ?

I see no reason to deprecate SHA2-256.=C2=A0 But I'm fine with a= ll the rest.

> iang

-derek
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--001a11c3b9defdfa64051cfb22f8-- From nobody Tue Aug 11 03:15:37 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBEA1A6FF6 for ; Tue, 11 Aug 2015 03:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 Q4rNq5qVvLTg for ; Tue, 11 Aug 2015 03:15:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B1E1A6FF0 for ; Tue, 11 Aug 2015 03:15:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZP6ah-0005wg-MS for ; Tue, 11 Aug 2015 12:15:31 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZP6W5-0007oW-6k; Tue, 11 Aug 2015 12:10:45 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , Derek Atkins , IETF OpenPGP , ianG Date: Tue, 11 Aug 2015 12:10:45 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 10 Aug 2015 16:50:32 -0400") Message-ID: <87si7qf84a.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 10:15:36 -0000 On Mon, 10 Aug 2015 22:50, phill@hallambaker.com said: > Given that email recipients tend to end up having to implement all the code > points in a cipher suite because they can't really control what is sent, I That is not the case with OpenPGP. If you encrypt and sign the key gives you a list of hash algorithms supported by the recipient. Only those may be used. In a signature only case there is no point in an using extravagant hash algorithm because most recipients won't be able to verify such a signature. We have a lot of experience in how to deploy new algorithms and we are very conservative here. My request for adding SHA3 algo ids does not mean in any way that I endorse its use or would even suggest that 4880bis should contain a SHOULD or MAY for implementing such an algorithm. When we come to the point on deciding on algorithms I would suggest something like this: - Implementations MUST implement SHA-1. Implementations MAY implement - other algorithms. MD5 is deprecated. + Implementations MUST implement SHA-1 and SHA2-FIXME. Implementations + MUST NOT implement MD5. Implementations SHOULD NOT implement + SHA3-xxxx. Implementations MAY implement other algorithms. The algo ids are a different case and I would be fine with the RFC-7120 method. Iff the unexpected case happens that a severe weakness in SHA2 is found, the pre-allocated SHA3 ids will allow us to quickly switch to SHA3. Isn't that the whole point of SHA3 being plugin-in replacements for SHA2? I suggest to use a different thread for discussing algorithm selection because that is a different topic than assigning algorithm ids. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 05:29:05 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ADE1A8931 for ; Tue, 11 Aug 2015 05:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 x2aquujL_tKU for ; Tue, 11 Aug 2015 05:29:02 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1271A1B14 for ; Tue, 11 Aug 2015 05:29:01 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A586F6D775; Tue, 11 Aug 2015 08:28:59 -0400 (EDT) Message-ID: <55C9EAA2.8040500@iang.org> Date: Tue, 11 Aug 2015 13:29:22 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <87si7qf84a.fsf@vigenere.g10code.de> In-Reply-To: <87si7qf84a.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 12:29:03 -0000 On 11/08/2015 11:10 am, Werner Koch wrote: ... > We have a lot of experience in how to deploy new algorithms and we are > very conservative here. My request for adding SHA3 algo ids does not > mean in any way that I endorse its use or would even suggest that > 4880bis should contain a SHOULD or MAY for implementing such an > algorithm. When we come to the point on deciding on algorithms I would > suggest something like this: > > - Implementations MUST implement SHA-1. Implementations MAY implement > - other algorithms. MD5 is deprecated. > + Implementations MUST implement SHA-1 and SHA2-FIXME. Implementations > + MUST NOT implement MD5. Implementations SHOULD NOT implement > + SHA3-xxxx. Implementations MAY implement other algorithms. > > The algo ids are a different case and I would be fine with the RFC-7120 > method. Iff the unexpected case happens that a severe weakness in SHA2 > is found, the pre-allocated SHA3 ids will allow us to quickly switch to > SHA3. Isn't that the whole point of SHA3 being plugin-in replacements > for SHA2? > > I suggest to use a different thread for discussing algorithm selection > because that is a different topic than assigning algorithm ids. Hmmm... I understand that. What I'm not convinced of is that at the current time we can sensibly allocate the numbers. As far as I can see, to sensibly allocate the numbers, we'd want: * to choose which SHA3 we're going for. This not only means addressing the additionals (like the 4 lengths) but also resolving the uncertainty (perhaps in my mind only) about SHAKES. * to build a more comprehensive alg-failure recovery strategy. By this I mean, more than handwaving at SHA3 as a potential drop in; making it the actual drop in with a process by which we trigger that move and a series of events listed that we anticipate happening; text in the draft that lays that out; etc. Otherwise, we're fortune gazing. (It may sound like I'm engaging in waffly rhetoric again - but there is a known discipline for this. It's called *disaster recovery* and it's a required component of many compliance programmes, taught and certified in various places. There are many people who know how to do this stuff, it's just that it is a relatively new and/or infrequent delivery in the open source crypto world.) iang From nobody Tue Aug 11 05:30:48 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA751A8958 for ; Tue, 11 Aug 2015 05:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Epv68FkFz6fP for ; Tue, 11 Aug 2015 05:30:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6D61A8956 for ; Tue, 11 Aug 2015 05:30:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mrD5w5Hrhz24C; Tue, 11 Aug 2015 14:30:44 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=pLvUIylc X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VKF_XKUJyMqs; Tue, 11 Aug 2015 14:30:43 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Aug 2015 14:30:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E085180042; Tue, 11 Aug 2015 08:30:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1439296242; bh=K92Kt0A1zkQFzlbwEQDRuOyl0I/GmSh5LEF1ihisAmM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pLvUIylcRzHW0Nx5OyN7uDDd/QTGZRWEbjXzE3UZvarjSFkNHZ2t8MnzzSGuBjRLo i7NKkyqPq+66eYEec8xxnms2fZUVUbIhJ1R0WTpjOkR3cgALxadCe0likSUuiqZc8x Xv8pKTjyAbjMIbQYcMH5l0UZHNvXAXRw8wrCJ9wg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t7BCUgup028559; Tue, 11 Aug 2015 08:30:42 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 11 Aug 2015 08:30:42 -0400 (EDT) From: Paul Wouters To: openpgp@ietf.org In-Reply-To: <87si7qf84a.fsf@vigenere.g10code.de> Message-ID: References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <87si7qf84a.fsf@vigenere.g10code.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Phillip Hallam-Baker Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 12:30:47 -0000 On Tue, 11 Aug 2015, Werner Koch wrote: > We have a lot of experience in how to deploy new algorithms and we are > very conservative here. My request for adding SHA3 algo ids does not > mean in any way that I endorse its use or would even suggest that > 4880bis should contain a SHOULD or MAY for implementing such an > algorithm. When we come to the point on deciding on algorithms I would > suggest something like this: > > - Implementations MUST implement SHA-1. Implementations MAY implement > - other algorithms. MD5 is deprecated. > + Implementations MUST implement SHA-1 and SHA2-FIXME. Implementations > + MUST NOT implement MD5. Implementations SHOULD NOT implement > + SHA3-xxxx. Implementations MAY implement other algorithms. openpgp is unique in that there is a _very_ long validity time required for some algorithms, so one could verify a 20 year old message, even if that security 20 years later is questionable (eg breakable) I would like to see (and maybe the documents already do that but the above bullet points don't indicicate this) a difference in support for verifying signatures (eg we should implement MD5 and MUST implement SHA1) and creating new signatures (MUST NOT use MD5 or SHA1) > The algo ids are a different case and I would be fine with the RFC-7120 > method. Iff the unexpected case happens that a severe weakness in SHA2 > is found, the pre-allocated SHA3 ids will allow us to quickly switch to > SHA3. Isn't that the whole point of SHA3 being plugin-in replacements > for SHA2? Yes, but I don't see why we need to have 6 versions of SHA3 on standbye. openpgp validity / security is measured in years, and as such, performance don't really come to play when considering algorithms. Paul From nobody Tue Aug 11 06:21:21 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000B81A8A51 for ; Tue, 11 Aug 2015 06:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bzFkVgiDVI4c for ; Tue, 11 Aug 2015 06:21:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE721A8A5A for ; Tue, 11 Aug 2015 06:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439299271; x=1470835271; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B03ZLgrqYH7rBvRciFKqRokH842X+MLY4jHNlAlm7Lk=; b=1V9T+KxA6TYUrb5SOGlfqqaLfml4/SWeR3C18i8EjCfdFFTmj/6skl8H TBiDi6qIAtm3x9FDqOl7pDusYsenEsdks5n4qIV/7rDncrqf1HNEK7MEy WSarrUF9xBnj3SX7Q0aMACM2ErqFBlCoh/1B1SuXfB+bP4DExoeYA0Orh nQ+yb+hAAboJP9caQzfhPGdQe74vUkPXsAqkNnOBon6Krltt2WtR3z9zS ZlcZetjR7KNHdJcZR5zS1hidBGeOFADetQBe7jc/Gf4l/DHreNEUU+ew0 2WUJvShrLThhMcZpAK5YUSjn12q0tqmJmwFJLqr4XkViAaA5YU1QuNAO3 A==; X-IronPort-AV: E=Sophos; i="5.15,653,1432555200"; d="scan'208,217"; a="34421461" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Aug 2015 01:21:08 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 12 Aug 2015 01:21:08 +1200 From: Peter Gutmann To: Phillip Hallam-Baker , Derek Atkins Thread-Topic: [openpgp] SHA3 algorithm ids. Thread-Index: AQHQ0bwwjUQponxgXEGSKRaVthfi2J4BQviAgACi0QCAA3eZy///kmAAgAHdvqo= Date: Tue, 11 Aug 2015 13:21:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73F4AD7C72uxcn105UoAauckl_" MIME-Version: 1.0 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 13:21:21 -0000 --_000_9A043F3CF02CD34C8E74AC1594475C73F4AD7C72uxcn105UoAauckl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker writes: >There is a very clear need for 512 bits and there is a case for 256 bits. What's the clear need for -512? By which I mean a demonstrated practical n= eed for a hash size of 64 bytes, not a hypothesised need given an imaginary attack. I can see a need for SHA-256 (to replace SHA-1), but for something like SHA3-512 all I can see are downsides (compared to SHA2-256). Peter. --_000_9A043F3CF02CD34C8E74AC1594475C73F4AD7C72uxcn105UoAauckl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Phillip Hallam-Baker <phill@hallambaker.com> writes:

>There is a very clear need for 512 bits and there is a= case for 256 bits.

What's the clear need for -512?  By which I mean a demonstrated practi= cal need
for a hash size of 64 bytes, not a hypothesised need given an imaginary
attack.  I can see a need for SHA-256 (to replace SHA-1), but for some= thing
like SHA3-512 all I can see are downsides (compared to SHA2-256).

Peter.

--_000_9A043F3CF02CD34C8E74AC1594475C73F4AD7C72uxcn105UoAauckl_-- From nobody Tue Aug 11 07:06:18 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D061A8AB6 for ; Tue, 11 Aug 2015 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 7m35imofRsvU for ; Tue, 11 Aug 2015 07:06:16 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 CE78F1A8AAE for ; Tue, 11 Aug 2015 07:06:15 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so6933682lbb.1 for ; Tue, 11 Aug 2015 07:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=BU9wLCMkFtlBRtZMulRXdnz4zb6e/skXQn3ujfoWbGM=; b=nIWFLBZHUoZ6UGYwzR8WePJOoF/zWIQl1uEX1qv24Gyr3KQpukefHxW2oJWAA2jgbU eWEXd4pdO/7eSseyRSMX7HY7E7hQRVOjU2PUdYijg2SzCBs0jCBsTx6eFVCE5TbYIisG Xw79dgIcSHOydZSnnX6vTQe8Wy7yOdPV2YBhJo57EtgI3ENyDezMfUmrIKxvUsCtSGGH 4+wd+1yxYQ0h3iNScgtNx5ua2C0qbGOgS03IBLCZEdYH1ftiqrdVkEpIIxtxJq7YDxMy Sv3yaOrPbhleared5MGbGnSwpBSdu4bLgnnvDs6UVJvMjxxEZ7RMp4/mlQC/6AUzhtdl zRSg== MIME-Version: 1.0 X-Received: by 10.112.16.225 with SMTP id j1mr26080104lbd.118.1439301974283; Tue, 11 Aug 2015 07:06:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 11 Aug 2015 07:06:14 -0700 (PDT) In-Reply-To: <87si7qf84a.fsf@vigenere.g10code.de> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <87si7qf84a.fsf@vigenere.g10code.de> Date: Tue, 11 Aug 2015 10:06:14 -0400 X-Google-Sender-Auth: 6bKUXevLkcrHZeUwf5A6QAvUjH0 Message-ID: From: Phillip Hallam-Baker To: Phillip Hallam-Baker , Derek Atkins , IETF OpenPGP , ianG Content-Type: multipart/alternative; boundary=001a11c3cb62e6db7d051d099a49 Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 14:06:17 -0000 --001a11c3cb62e6db7d051d099a49 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 6:10 AM, Werner Koch wrote: > On Mon, 10 Aug 2015 22:50, phill@hallambaker.com said: > > > Given that email recipients tend to end up having to implement all the > code > > points in a cipher suite because they can't really control what is sent, > I > > That is not the case with OpenPGP. If you encrypt and sign the key > gives you a list of hash algorithms supported by the recipient. Only > those may be used. In a signature only case there is no point in an using > extravagant hash algorithm because most recipients won't be able to > verify such a signature. > And what then happens if you use the same key on two different devices running two different applications? Advertising crypto capabilities is good. But it isn't a panacea. If people are going to use end to end encrypted email as default, they have to be able to read their mail on multiple devices. --001a11c3cb62e6db7d051d099a49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 11, 2015 at 6:10 AM, Werner Koch <wk@gnupg.org> wrote:
On Mon, 10 Aug 2015 22:50,= phill@hallambaker.com said:
> Given that email recipients tend to end up having to implement all the= code
> points in a cipher suite because they can't really control what is= sent, I

That is not the case with OpenPGP.=C2=A0 If you encrypt and sign the= key
gives you a list of hash algorithms supported by the recipient.=C2=A0 Only<= br> those may be used.=C2=A0 =C2=A0In a signature only case there is no point i= n an using
extravagant hash algorithm because most recipients won't be able to
verify such a signature.

And what then = happens if you use the same key on two different devices running two differ= ent applications?

Advertising crypto capabilities = is good. But it isn't a panacea. If people are going to use end to end = encrypted email as default, they have to be able to read their mail on mult= iple devices.
=C2=A0
--001a11c3cb62e6db7d051d099a49-- From nobody Tue Aug 11 07:16:48 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F981A8AC2 for ; Tue, 11 Aug 2015 07:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 KL5lj0HX_oTj for ; Tue, 11 Aug 2015 07:16:45 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 0B4C61A8A99 for ; Tue, 11 Aug 2015 07:16:45 -0700 (PDT) Received: by lagz9 with SMTP id z9so71772013lag.3 for ; Tue, 11 Aug 2015 07:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iraCo0HiTRoerlbgMe+2RMxZGTFxr2/HsxHWAYUM26g=; b=p9g29MkXlt0vBVDR+rM3XiywVBEe2jL1lWgpYzFAgDDIS6NM6bnCnRpWymqiLW45G5 Vhf0AczWME9/4hipwySOSi/t83cEY3KfslSF1PZPQ4S3btF3i/oFppWmJIfxDgNbHjUO 1ntPLjAx3vcs6HNAf2Li1fopsPcsylO/RnpwXMAW2V6faeMKH4j/JQdvWTUfJo2+2+GQ GLHCp4CI6faTNKTLxaBewGQwky47zYodYieTK93hnJ3empH3zZHhWotS6KTFFrRSUX4o dt8QosU/LoHNH9gGxFlImueMtBhiEePlA+KlRAUfYDZwzeLrlXAtmPEL7VbwXRvsK23C 2SiQ== MIME-Version: 1.0 X-Received: by 10.112.126.65 with SMTP id mw1mr9591934lbb.124.1439302603350; Tue, 11 Aug 2015 07:16:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 11 Aug 2015 07:16:43 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 11 Aug 2015 10:16:43 -0400 X-Google-Sender-Auth: _ckGu9yHXPTMtNASHkGjSXASLIs Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a11c3693665aaa6051d09c043 Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 14:16:46 -0000 --001a11c3693665aaa6051d09c043 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 9:21 AM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > > >There is a very clear need for 512 bits and there is a case for 256 bits. > > What's the clear need for -512? By which I mean a demonstrated practical > need > for a hash size of 64 bytes, not a hypothesised need given an imaginary > attack. I can see a need for SHA-256 (to replace SHA-1), but for something > like SHA3-512 all I can see are downsides (compared to SHA2-256). > The CFRG replacement for ECDSA will almost certainly use the 512 bit wide pipe hash internally. Dan Bernstein put together a Perl script that shows every algorithm and every option. If you are going to sign a 1Gb file then you are going to need multiple trips through the digest function. Now there is of course a good argument to be made for a faster 256 bit hash for the bulk digest on that 1Gb file. But you also need one or more digests of fixed bits of data internally. So the practical upshot is that if we were to define an absolutely minimal cryptolib it would almost certainly include the 512 bit digest. The 256 bit is optional. Constrained devices still exist. But the constraint on processing speed is easing up much more quickly than the constraint on code space and working memory. --001a11c3693665aaa6051d09c043 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 11, 2015 at 9:21 AM, Peter Gutmann <pgut001@cs.auc= kland.ac.nz> wrote:
Phillip Hallam-Baker <phill@hallambaker.com> writes:

>There is a very clear need for 512 bi= ts and there is a case for 256 bits.

What's the clear need for -512?=C2=A0 By which I mean a demonstrated pr= actical need
for a hash size of 64 bytes, not a hypothesised need given an imaginary
attack.=C2=A0 I can see a need for SHA-256 (to replace SHA-1), but for some= thing
like SHA3-512 all I can see are downsides (compared to SHA2-256).
<= /blockquote>

The CFRG replacement for ECDSA will almost = certainly use the 512 bit wide pipe hash internally.

Dan Bernstein put together a Perl script that shows every algorithm and = every option. If you are going to sign a 1Gb file then you are going to nee= d multiple trips through the digest function. Now there is of course a good= argument to be made for a faster 256 bit hash for the bulk digest on that = 1Gb file. But you also need one or more digests of fixed bits of data inter= nally.=C2=A0

So the practical upshot is that if we= were to define an absolutely minimal cryptolib it would almost certainly i= nclude the 512 bit digest. The 256 bit is optional.


Constrained devices still exist. But the constraint on pro= cessing speed is easing up much more quickly than the constraint on code sp= ace and working memory.

--001a11c3693665aaa6051d09c043-- From nobody Tue Aug 11 08:46:41 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915EC1A0174 for ; Tue, 11 Aug 2015 08:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 YT4im_unX5uj for ; Tue, 11 Aug 2015 08:46:39 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEDE1A1A56 for ; Tue, 11 Aug 2015 08:45:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPBk3-0001bs-Uj for ; Tue, 11 Aug 2015 17:45:31 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPBfs-00027e-Gw; Tue, 11 Aug 2015 17:41:12 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , Peter Gutmann , IETF OpenPGP , Derek Atkins , ianG Date: Tue, 11 Aug 2015 17:41:12 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 11 Aug 2015 10:16:43 -0400") Message-ID: <87a8txg7dz.fsf_-_@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG , Peter Gutmann Subject: [openpgp] Why or why not SHA{2,3}-512 (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 15:46:40 -0000 On Tue, 11 Aug 2015 16:16, phill@hallambaker.com said: > every option. If you are going to sign a 1Gb file then you are going to > need multiple trips through the digest function. Now there is of course a This is not an option for OpenPGP! OpenPGP has been carefully designed to allow its use in a pipe ("online" in current parlance). Any signing function which requires multiple passes over the signed data is useless. (I heard of encrypted(+signed) backups in the TiB range.) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 08:50:41 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C3E1A1A56 for ; Tue, 11 Aug 2015 08:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 PKeS1WP2FAXe for ; Tue, 11 Aug 2015 08:50:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A581A1A20 for ; Tue, 11 Aug 2015 08:50:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPBou-0001hl-VP for ; Tue, 11 Aug 2015 17:50:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPBmM-00028k-Fw; Tue, 11 Aug 2015 17:47:54 +0200 From: Werner Koch To: Peter Gutmann References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Phillip Hallam-Baker , Derek Atkins , IETF OpenPGP , ianG Date: Tue, 11 Aug 2015 17:47:54 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 11 Aug 2015 13:21:07 +0000") Message-ID: <87614lg72t.fsf_-_@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , Derek Atkins , ianG , IETF OpenPGP Subject: [openpgp] WWhy or why not SHA{2,3}-512 (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 15:50:35 -0000 On Tue, 11 Aug 2015 15:21, pgut001@cs.auckland.ac.nz said: > What's the clear need for -512? By which I mean a demonstrated practical need > for a hash size of 64 bytes, not a hypothesised need given an imaginary > attack. I can see a need for SHA-256 (to replace SHA-1), but for something > like SHA3-512 all I can see are downsides (compared to SHA2-256). One advantage of SHA-512 (SHA2) is that it faster than SHA-256 on modern machines. Thus SHA-512 truncated to 256 might be an option. This would eventually allow to write a small application which uses SHA-512 as its only hash algorithm. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 09:05:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E351AC3F2 for ; Tue, 11 Aug 2015 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 d2g_JKHB9_WA for ; Tue, 11 Aug 2015 09:05:33 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555DA1AC3EE for ; Tue, 11 Aug 2015 09:05:33 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPC3P-0001yB-IJ for ; Tue, 11 Aug 2015 18:05:31 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPC1R-0002C6-1L; Tue, 11 Aug 2015 18:03:29 +0200 From: Werner Koch To: Paul Wouters References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <87si7qf84a.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , openpgp@ietf.org, Phillip Hallam-Baker Date: Tue, 11 Aug 2015 18:03:28 +0200 In-Reply-To: (Paul Wouters's message of "Tue, 11 Aug 2015 08:30:42 -0400 (EDT)") Message-ID: <871tf9g6cv.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org, Phillip Hallam-Baker Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:05:34 -0000 On Tue, 11 Aug 2015 14:30, paul@nohats.ca said: > openpgp is unique in that there is a _very_ long validity time required > for some algorithms, so one could verify a 20 year old message, even if > that security 20 years later is questionable (eg breakable) I think that it is not yet the time to discuss deprecation of algorithms or new standard preferences; this can and should be delayed until we have done the bulk of 4880bis work. > Yes, but I don't see why we need to have 6 versions of SHA3 on standbye. Only 4 can be used as direct replacements. SHAKE would only make sense if we adjust the used signature algorithms. > openpgp validity / security is measured in years, and as such, > performance don't really come to play when considering algorithms. Having the ids allocated allows to switch to them without much discussion. If you really want, we could also say these numbers are re severed for SHA3 so that it is clear that they should not be used. But that is bascially what RFC-7120 does after a year. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 09:10:39 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31001AC40C for ; Tue, 11 Aug 2015 09:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 oqyvX3XvfUCx for ; Tue, 11 Aug 2015 09:10:33 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30951AC405 for ; Tue, 11 Aug 2015 09:10:32 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPC8F-000231-9y for ; Tue, 11 Aug 2015 18:10:31 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPC5y-0002DP-RK; Tue, 11 Aug 2015 18:08:10 +0200 From: Werner Koch To: ianG References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <87si7qf84a.fsf@vigenere.g10code.de> <55C9EAA2.8040500@iang.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: ianG , openpgp@ietf.org Date: Tue, 11 Aug 2015 18:08:10 +0200 In-Reply-To: <55C9EAA2.8040500@iang.org> (iang@iang.org's message of "Tue, 11 Aug 2015 13:29:22 +0100") Message-ID: <87wpx1erkl.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:10:38 -0000 On Tue, 11 Aug 2015 14:29, iang@iang.org said: > * to choose which SHA3 we're going for. This not only means > addressing the additionals (like the 4 lengths) but also resolving the > uncertainty (perhaps in my mind only) about SHAKES. I don't think so. Let's assume that 4880bis specifies SHA-256 as the replacement for SHA throughout the protocol. Then it would be pretty clear that SHA3-256 can be used if surprisingly a Chinese researcher finds weaknesses in SHA2. > * to build a more comprehensive alg-failure recovery strategy. By > this I mean, more than handwaving at SHA3 as a potential drop in; > making it the actual drop in with a process by which we trigger that We already have this. The preference systems greatly helped with the migration from SHA-1 to SHA-256 et al. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 09:14:26 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF01AC3D2 for ; Tue, 11 Aug 2015 09:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 xhUj6ZoL2z5L for ; Tue, 11 Aug 2015 09:14:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADA51AC3D5 for ; Tue, 11 Aug 2015 09:14:24 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 65326F984; Tue, 11 Aug 2015 12:14:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E6A2520057; Tue, 11 Aug 2015 18:14:11 +0200 (CEST) From: Daniel Kahn Gillmor To: Peter Gutmann , Phillip Hallam-Baker , Derek Atkins In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 11 Aug 2015 12:14:11 -0400 Message-ID: <87io8lpzu4.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:14:25 -0000 On Tue 2015-08-11 09:21:07 -0400, Peter Gutmann wrote: > What's the clear need for -512? By which I mean a demonstrated practical need > for a hash size of 64 bytes, not a hypothesised need given an imaginary > attack. I can see a need for SHA-256 (to replace SHA-1), but for something > like SHA3-512 all I can see are downsides (compared to SHA2-256). Is your concern CPU time or bandwidth (network/storage) or something else? If it's CPU time: on some architectures SHA-512 implementations are faster than SHA-256 implementations (except for digests of very short messages): 0 dkg@alice:~$ openssl speed sha512 sha256 Doing sha256 for 3s on 16 size blocks: 9475191 sha256's in 3.00s Doing sha256 for 3s on 64 size blocks: 5366754 sha256's in 3.00s Doing sha256 for 3s on 256 size blocks: 2344003 sha256's in 3.00s Doing sha256 for 3s on 1024 size blocks: 715128 sha256's in 3.00s Doing sha256 for 3s on 8192 size blocks: 96700 sha256's in 3.00s Doing sha512 for 3s on 16 size blocks: 7094449 sha512's in 3.00s Doing sha512 for 3s on 64 size blocks: 7048926 sha512's in 3.00s Doing sha512 for 3s on 256 size blocks: 2764993 sha512's in 3.00s Doing sha512 for 3s on 1024 size blocks: 972785 sha512's in 3.00s Doing sha512 for 3s on 8192 size blocks: 136283 sha512's in 3.00s OpenSSL 1.0.2d 9 Jul 2015 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 50534.35k 114490.75k 200021.59k 244097.02k 264055.47k sha512 37837.06k 150377.09k 235946.07k 332043.95k 372143.45k 0 dkg@alice:~$ extra speed is hardly a downside. :) --dkg From nobody Tue Aug 11 09:23:04 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0F1ACCFF for ; Tue, 11 Aug 2015 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URI_HEX=1.122] autolearn=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 k_MXCQuluobs for ; Tue, 11 Aug 2015 09:23:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAC51ACCFE for ; Tue, 11 Aug 2015 09:22:59 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A3BA4F984; Tue, 11 Aug 2015 12:22:57 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D154A203F5; Tue, 11 Aug 2015 18:22:57 +0200 (CEST) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , Peter Gutmann In-Reply-To: References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 11 Aug 2015 12:22:57 -0400 Message-ID: <87fv3ppzfi.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:23:03 -0000 On Tue 2015-08-11 10:16:43 -0400, Phillip Hallam-Baker wrote: > The CFRG replacement for ECDSA will almost certainly use the 512 bit wide > pipe hash internally. > > Dan Bernstein put together a Perl script that shows every algorithm and > every option. for those who haven't followed that process, djb's python script is here: http://ed25519.cr.yp.to/cfrg/signatures.py > If you are going to sign a 1Gb file then you are going to need > multiple trips through the digest function. Now there is of course a > good argument to be made for a faster 256 bit hash for the bulk digest > on that 1Gb file. (except when the 512-bit hash is faster for the bulk digest, see my earlier post in this thread) > Constrained devices still exist. But the constraint on processing speed is > easing up much more quickly than the constraint on code space and working > memory. The other constraints to consider are network bandwidth and permanent storage. But compared to the move from strong RSA to (any reasonable form of) ECC (e.g. the variable part of keys/signatures/PKESKs going from 2048 bits or more to 521 bits or less), the difference between a 256-bit hash and a 512-bit hash seems nearly lost in the noise. --dkg From nobody Tue Aug 11 09:39:33 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226BE1ACD7A for ; Tue, 11 Aug 2015 09:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cJHJSctcyfeH for ; Tue, 11 Aug 2015 09:39:25 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C094F1ACD79 for ; Tue, 11 Aug 2015 09:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439311164; x=1470847164; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a4BRpbiFly9zl2tt2QUEYMX6wjaF8McyJL2fBQ6Sz1k=; b=HFniPp1KhvknfmiTp1O92YZ5QbxdLEv3Nkzvtz4Qv5pxh3SUjhrT0wya AZvus9wHj9OGVNX+JlzOCP+rVkHdxRi+nkntn9DE3bnHVq9iZ2+d4YhLa nrTI9WcJ5qDpFY7lCjl+kK3JaeTM/JufCzwmxCyFzk7QDac7Ge7uwWoe0 Di6uBkzWXHedVy+AjkYZMOevnQ36UW6MAfTROuAulLaBJiuJkjCQEZRRH lDauUtbnpvLWv1C03MblVzKaF79l2sRQYXCrC8NDf6ui5inciXjd8LXIo YSy0IWFmS0srMR9LuBWG96KV7ms7p9wY33a7GJJEzega5jQTv+bYslYlF w==; X-IronPort-AV: E=Sophos;i="5.15,654,1432555200"; d="scan'208";a="34432483" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Aug 2015 04:39:22 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 12 Aug 2015 04:39:22 +1200 From: Peter Gutmann To: Daniel Kahn Gillmor , Phillip Hallam-Baker , Derek Atkins Thread-Topic: [openpgp] SHA3 algorithm ids. Thread-Index: AQHQ0bwwjUQponxgXEGSKRaVthfi2J4BQviAgACi0QCAA3eZy///kmAAgAHdvqr//2dhgIAAz/XS Date: Tue, 11 Aug 2015 16:39:21 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz>, <87io8lpzu4.fsf@alice.fifthhorseman.net> In-Reply-To: <87io8lpzu4.fsf@alice.fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:39:32 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >Is your concern CPU time or bandwidth (network/storage) or something else?= =0A= =0A= Yes.=0A= =0A= >If it's CPU time: on some architectures SHA-512 implementations are faster= =0A= >than SHA-256 implementations (except for digests of very short messages):= =0A= =0A= A huge number of devices, and in particular ones with less CPU power, are= =0A= still 32-bit, and will remain so for a long time, probably more or less=0A= indefinitely.=0A= =0A= In addition from the original post it was unclear whether -512 referred to= =0A= SHA2 or SHA3 (which is why I qualified my reply as SHA2-256 and SHA3-512),= =0A= SHA3 will be ever worse than SHA2-512 in speed terms.=0A= =0A= In terms of network/storage, there's the unnecessary use of 64-byte hashes= =0A= that I've already mentioned. For TLS and SSH you really don't need more th= an=0A= maybe 64 bits (not bytes), and certainly 64 bytes is nothing more than a=0A= pointless waste of space when you're sending lots of small data quantities= =0A= back and forth.=0A= =0A= Peter.= From nobody Tue Aug 11 10:30:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD401ACE06 for ; Tue, 11 Aug 2015 10:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WoeKXmBn9LIV for ; Tue, 11 Aug 2015 10:30:33 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A221ACDFF for ; Tue, 11 Aug 2015 10:30:33 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPDNf-0002g4-HH for ; Tue, 11 Aug 2015 19:30:31 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPDMp-0002Px-QV; Tue, 11 Aug 2015 19:29:39 +0200 From: Werner Koch To: Peter Gutmann References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Daniel Kahn Gillmor , Phillip Hallam-Baker , Derek Atkins , IETF OpenPGP , ianG Date: Tue, 11 Aug 2015 19:29:39 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 11 Aug 2015 16:39:21 +0000") Message-ID: <87mvxxenss.fsf_-_@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , Derek Atkins , ianG , Daniel Kahn Gillmor , IETF OpenPGP Subject: [openpgp] SHA-x performance (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:30:34 -0000 On Tue, 11 Aug 2015 18:39, pgut001@cs.auckland.ac.nz said: > A huge number of devices, and in particular ones with less CPU power, are > still 32-bit, and will remain so for a long time, probably more or less > indefinitely. Does anyone know a summary of SHA-256 performance on standard CPUs with dedicated SHA hardware? The Padlock engine has this but I don't know whether other CPUs also provide hardware support. I assume that on x86 the AVX instructions are as good as dedicated support: FWIW, Libgcrypt on an i5-2410M (64 bit) gives this: | nanosecs/byte mebibytes/sec cycles/byte SHA1 | 1.92 ns/B 496.5 MiB/s 4.42 c/B SHA256 | 4.42 ns/B 215.6 MiB/s 10.17 c/B SHA512 | 2.97 ns/B 321.1 MiB/s 6.83 c/B with AVX disabled: SHA1 | 2.27 ns/B 419.7 MiB/s 5.23 c/B SHA256 | 5.26 ns/B 181.1 MiB/s 12.11 c/B SHA512 | 3.61 ns/B 264.0 MiB/s 8.31 c/B with AVX and SSSE3 disabled: SHA1 | 3.27 ns/B 292.0 MiB/s 7.51 c/B SHA256 | 7.50 ns/B 127.1 MiB/s 17.26 c/B SHA512 | 4.68 ns/B 203.6 MiB/s 10.78 c/B We have no optimized SHA3 yet; for reference here are the numbers from the unoptimized version: SHA3-256 | 5.70 ns/B 167.3 MiB/s 13.11 c/B SHA3-512 | 10.66 ns/B 89.46 MiB/s 24.52 c/B Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 10:45:41 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B411ACE28 for ; Tue, 11 Aug 2015 10:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 H3FhT3FmVSjB for ; Tue, 11 Aug 2015 10:45:38 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A31ACE23 for ; Tue, 11 Aug 2015 10:45:38 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 758A5F984 for ; Tue, 11 Aug 2015 13:45:37 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 58573207E1; Tue, 11 Aug 2015 19:45:37 +0200 (CEST) From: Daniel Kahn Gillmor To: IETF OpenPGP In-Reply-To: <87mvxxenss.fsf_-_@vigenere.g10code.de> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 11 Aug 2015 13:45:37 -0400 Message-ID: <87a8txpvlq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] SHA-x performance (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:45:39 -0000 On Tue 2015-08-11 13:29:39 -0400, Werner Koch wrote: > FWIW, Libgcrypt on an i5-2410M (64 bit) gives this: I'm assuming this is done over large inputs KiB or MiB of data into each hash -- is that right? can you indicate what commands you ran to generate these figures? > | nanosecs/byte mebibytes/sec cycles/byte Thank you for the precise and clear units! that's (sadly) pretty rare to see in performance test reports, but it's very helpful. --dkg From nobody Tue Aug 11 10:49:05 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086941ACE27 for ; Tue, 11 Aug 2015 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 N37skBhigUfl for ; Tue, 11 Aug 2015 10:49:01 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9AA1AC3E2 for ; Tue, 11 Aug 2015 10:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439315342; x=1470851342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=D+q1otGRl5xJRSgsjRH9+dGOCYfU8jsfFbf+qqTtjh4=; b=MIEyESApGNzZtjNrZs5lke8iB60jp3ojmNSsUKzVjNZ4wRcLoN0cWXkR DLoqTDDwMbq3lnk78aIiV/FcjwsvsSqkRtRxrJgK+iJb0tAsC1ay7vHmR y3flPdq8kMnN79qTsT6Pivki2rRPu18gtwKElhxU7PzVvgAg0SDOXmjsx BOurP9xjkYq09eRfND8ELUffG41qYzeX18jME+rxwM72AYLXWGIUITTy2 HBO/knE8fp8ea6JJPRJqHi1POQIO66J6FAKEEMAZcUdZqWCvU1ameeh0A 5uEbCPJ8H08VA8oV5hRU5CntdUajOMD4rINz+EkrZ6LzMl7rVkXbCv2di Q==; X-IronPort-AV: E=Sophos;i="5.15,654,1432555200"; d="scan'208";a="34435902" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Aug 2015 05:49:01 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 12 Aug 2015 05:48:59 +1200 From: Peter Gutmann To: Werner Koch Thread-Topic: SHA-x performance (was: [openpgp] SHA3 algorithm ids) Thread-Index: AQHQ1FtvD5rLGhGylEatY9bW9pkXy54HEj++ Date: Tue, 11 Aug 2015 17:48:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz>, <87mvxxenss.fsf_-_@vigenere.g10code.de> In-Reply-To: <87mvxxenss.fsf_-_@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Phillip Hallam-Baker , Derek Atkins , ianG , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] SHA-x performance (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:49:04 -0000 Werner Koch writes:=0A= =0A= >Does anyone know a summary of SHA-256 performance on standard CPUs with=0A= >dedicated SHA hardware?=0A= =0A= This is focusing on entirely the wrong end of the performance scale,=0A= benchmarking anything on an i7 (or whatever) is pretty much irrelevant beca= use=0A= no matter how you implement it (with hardware assist, software-only, handco= ded=0A= asm, C, Visual Basic, whatever), it's still going to be way faster than you= =0A= ever need. The only difference will be whether it's 100x faster than requi= red=0A= or 200x faster. =0A= =0A= Where it matters is IoT implementations, 180MHz STM32's and the like. For= =0A= example on a Cortex A7 (which is way more powerful than most IoT devices us= e,=0A= but I happen to have figures at hand for it), SHA2-512 is more than an orde= r=0A= of magnitude slower than SHA2-256. SHA-3 is too new to have figures=0A= available, but I'd guess it's going to be a lot worse than that. That's wh= at=0A= you need to benchmark for, systems where speed is actually an issue.=0A= =0A= Peter.= From nobody Tue Aug 11 10:54:03 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1527C1AC3DB for ; Tue, 11 Aug 2015 10:54:02 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TM7fIMOIHWZg for ; Tue, 11 Aug 2015 10:54:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C981ACD5D for ; Tue, 11 Aug 2015 10:53:59 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 11 Aug 2015 17:53:42 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0225.018; Tue, 11 Aug 2015 17:53:42 +0000 From: "Dang, Quynh" To: "openpgp@ietf.org" Thread-Topic: [openpgp] SHA-x performance (was: SHA3 algorithm ids) Thread-Index: AQHQ1Ftzvt9tXi6HgkmsLI1jzKk6yZ4HE0oq Date: Tue, 11 Aug 2015 17:53:42 +0000 Message-ID: References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz>, <87mvxxenss.fsf_-_@vigenere.g10code.de> In-Reply-To: <87mvxxenss.fsf_-_@vigenere.g10code.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.230.6] x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:vzPVEef1Dx+sOX2ioqNYbyUJSJziQFMOkfTcu2D+wnT+HEUYlUUS8yHuhUNI8hWwiIlfiwfyQeK24sLjhET0NEz3xltKlrN/B5w3uWZ28XbS3KAzoAd7AosxpJQ7cegKTd0OY6i6Iibib3JMHsET4Q==; 24:Am/FNH04hqTWnQYtESUwgu3OSo0SjVafA8JiEAyA0hWKVMSAVB2LPmjWqzVVfAvQj8qIBb4DOGozhiIOM1qfCGzPXJrCd8FE4/OGmL3MJKY=; 20:42lAFrrFT9ZoXaIMh/uBFM2GET34MiKaH7uYL4xOJnAM7QigKlWw2kQNWxq1kewl8aYhGLcl4sHccP+/hnTJ6A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(92566002)(2501003)(5002640100001)(110136002)(122556002)(40100003)(76176999)(33656002)(106356001)(62966003)(93886004)(46102003)(19580395003)(86362001)(5001860100001)(105586002)(74316001)(19580405001)(106116001)(5001830100001)(189998001)(77156002)(99286002)(66066001)(81156007)(87936001)(107886002)(2656002)(5001960100002)(76576001)(102836002)(68736005)(4001540100001)(77096005)(2351001)(64706001)(450100001)(101416001)(54356999)(2900100001)(10400500002)(5003600100002)(2950100001)(97736004)(50986999)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2015 17:53:42.7615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Subject: Re: [openpgp] SHA-x performance (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:54:02 -0000 See the Keccak's website: http://keccak.noekeon.org/, under the "Implementa= tion" section. It stated that "Keccak has overall good software performance. It is faster = than SHA-2 on modern PCs and shines when used in a mode exploiting parallel= ism. On AMD=99 Bulldozer=99, 128-bit and 256-bit security hashing tops at 4= .8 and 5.9 cycles/byte, respectively. On Intel=99 Sandy Bridge=99, the same= functions reach 5.4 and 6.9 cycles/byte." Quynh.=20 ________________________________________ From: openpgp on behalf of Werner Koch Sent: Tuesday, August 11, 2015 1:29 PM To: Peter Gutmann Cc: Phillip Hallam-Baker; Derek Atkins; ianG; Daniel Kahn Gillmor; IETF Ope= nPGP Subject: [openpgp] SHA-x performance (was: SHA3 algorithm ids) On Tue, 11 Aug 2015 18:39, pgut001@cs.auckland.ac.nz said: > A huge number of devices, and in particular ones with less CPU power, are > still 32-bit, and will remain so for a long time, probably more or less > indefinitely. Does anyone know a summary of SHA-256 performance on standard CPUs with dedicated SHA hardware? The Padlock engine has this but I don't know whether other CPUs also provide hardware support. I assume that on x86 the AVX instructions are as good as dedicated support: FWIW, Libgcrypt on an i5-2410M (64 bit) gives this: | nanosecs/byte mebibytes/sec cycles/byte SHA1 | 1.92 ns/B 496.5 MiB/s 4.42 c/B SHA256 | 4.42 ns/B 215.6 MiB/s 10.17 c/B SHA512 | 2.97 ns/B 321.1 MiB/s 6.83 c/B with AVX disabled: SHA1 | 2.27 ns/B 419.7 MiB/s 5.23 c/B SHA256 | 5.26 ns/B 181.1 MiB/s 12.11 c/B SHA512 | 3.61 ns/B 264.0 MiB/s 8.31 c/B with AVX and SSSE3 disabled: SHA1 | 3.27 ns/B 292.0 MiB/s 7.51 c/B SHA256 | 7.50 ns/B 127.1 MiB/s 17.26 c/B SHA512 | 4.68 ns/B 203.6 MiB/s 10.78 c/B We have no optimized SHA3 yet; for reference here are the numbers from the unoptimized version: SHA3-256 | 5.70 ns/B 167.3 MiB/s 13.11 c/B SHA3-512 | 10.66 ns/B 89.46 MiB/s 24.52 c/B Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ openpgp mailing list openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp= From nobody Tue Aug 11 13:05:37 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168C21B2A15 for ; Tue, 11 Aug 2015 13:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 oRlFDIw4NIgA for ; Tue, 11 Aug 2015 13:05:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2751AC427 for ; Tue, 11 Aug 2015 13:05:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPFng-0003tJ-Go for ; Tue, 11 Aug 2015 22:05:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPFjW-0002ln-0I; Tue, 11 Aug 2015 22:01:14 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <87a8txpvlq.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 11 Aug 2015 22:01:13 +0200 In-Reply-To: <87a8txpvlq.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 11 Aug 2015 13:45:37 -0400") Message-ID: <87d1ytegs6.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 20:05:36 -0000 On Tue, 11 Aug 2015 19:45, dkg@fifthhorseman.net said: > I'm assuming this is done over large inputs KiB or MiB of data into each > hash -- is that right? can you indicate what commands you ran to > generate these figures? The values are taken from mesurements of 64 buffer sizes from 16 to 4112 bytes. Result should be somewhat similar to SUPERCOP. I ran this from current Libgcrypt master: tests/bench-slope --cpu-mhz 2300 \ --disable-hwf intel-avx --disable-hwf intel-ssse3 \ hash sha1 sha256 sha512 sha3-256 sha3-512 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 13:08:33 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803521B2A30 for ; Tue, 11 Aug 2015 13:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 NQ2pEtTrMgiJ for ; Tue, 11 Aug 2015 13:08:31 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC081B2A2A for ; Tue, 11 Aug 2015 13:08:30 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9B6116D73E; Tue, 11 Aug 2015 16:08:29 -0400 (EDT) Message-ID: <55CA5654.4000400@iang.org> Date: Tue, 11 Aug 2015 21:08:52 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <87si7qf84a.fsf@vigenere.g10code.de> <55C9EAA2.8040500@iang.org> <87wpx1erkl.fsf@vigenere.g10code.de> In-Reply-To: <87wpx1erkl.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 20:08:32 -0000 On 11/08/2015 17:08 pm, Werner Koch wrote: > On Tue, 11 Aug 2015 14:29, iang@iang.org said: > >> * to choose which SHA3 we're going for. This not only means >> addressing the additionals (like the 4 lengths) but also resolving the >> uncertainty (perhaps in my mind only) about SHAKES. > > I don't think so. Let's assume that 4880bis specifies SHA-256 as the > replacement for SHA throughout the protocol. Then it would be pretty > clear that SHA3-256 can be used if surprisingly a Chinese researcher > finds weaknesses in SHA2. This assumes that any future breach of SHA2 is of the class that we can then drop in a replacement from SHA3 -- without any change. Eg, a prediction that the Chinese researcher attack actually comes true a second time. I find this unlikely. We're fighting a mythical enemy here, indeed the Chinese research attacker hasn't as yet actually count coup [0] on SHA1 let alone SHA2 :) I suggest we get back to other things, we're wheel-spinning. If you really want to allocate those numbers, go ahead - I think it is pointless but it does no harm to the document, and it's better to move on. >> * to build a more comprehensive alg-failure recovery strategy. By >> this I mean, more than handwaving at SHA3 as a potential drop in; >> making it the actual drop in with a process by which we trigger that > > We already have this. The preference systems greatly helped with the > migration from SHA-1 to SHA-256 et al. OK, I'd have to review that in the doc. (But I don't have time, so I'll defer.) iang [0] old Hollywood term for scalping the enemy in westerns. From nobody Tue Aug 11 13:35:36 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8321B2A5D for ; Tue, 11 Aug 2015 13:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Tcl4tzSQ5vGe for ; Tue, 11 Aug 2015 13:35:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4C51B2A1F for ; Tue, 11 Aug 2015 13:35:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPGGi-0004Ev-Gk for ; Tue, 11 Aug 2015 22:35:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPGDL-0002qP-Gw; Tue, 11 Aug 2015 22:32:03 +0200 From: Werner Koch To: Peter Gutmann References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Phillip Hallam-Baker , Derek Atkins , ianG , Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 11 Aug 2015 22:32:03 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 11 Aug 2015 17:48:59 +0000") Message-ID: <878u9hefcs.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , Phillip Hallam-Baker , Derek Atkins , Daniel Kahn Gillmor , ianG Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 20:35:35 -0000 On Tue, 11 Aug 2015 19:48, pgut001@cs.auckland.ac.nz said: > asm, C, Visual Basic, whatever), it's still going to be way faster than you > ever need. The only difference will be whether it's 100x faster than required > or 200x faster. Depends on what you want to do: To feed a big pipe you will need a reasonable fast CPU anyway because there are other things to do beside crypto. Thus it matters for those applications whether you can you still use a cheaper CPU. > Where it matters is IoT implementations, 180MHz STM32's and the like. For > example on a Cortex A7 (which is way more powerful than most IoT devices use, Right that is a different class but fortunately we can run our protocols easily there. I concur that a MUST algorithm in OpenPGP should work well on small devices. This is also the reason why one algorithm _might_ not fit all devices. bench.cr.yp.to has a lot data points but AFAICS it start with an A8 and it any case there is too much data for a useful discussion. Do you have a suggestion on what CPUs from low to high end to do benchmarks so to check which SHA variant is suitable? Although, I assume that SHA-256 will likely be the best over all CPUs, having some concrete data points may help to convince other folks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Aug 11 14:22:15 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85B81B2ACB for ; Tue, 11 Aug 2015 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6T0E6R0YQKbi for ; Tue, 11 Aug 2015 14:22:13 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 2DED51B2ADF for ; Tue, 11 Aug 2015 14:20:05 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so37313671lbb.0 for ; Tue, 11 Aug 2015 14:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=kclfyLoUyzLUkdKe9dqlRJtlLOgXuov7etkAvpKdMhA=; b=e+rviN9GlxuQhui0/0VIpY5mgrnpElJNvupl44d+XiNPjSR1RMhc6xtpQGLpeTxl3D b91FTFQG/2GSn1Db8VHIKihCNPr9oYvZ8Em86kHYwfBikyz420XS/oTtIY+l2epFNcol G3dVnRmKyVL3+NVuzbgzzyq3xdxO8m2AFSOpY3P1WcEWnGhxaqUXewsSYEYz/mHxhd5/ naMJ3o1EJSowyotX4A9dkZfISbc9g40EcC/Y3BhIvpGeZWFzvwQrZIr+yF6k4lJ9bHGL xZm412HcdIp+IpZJPT/BbnC68RBSUwv9mZjU686PE5gnj8IUxZBOEIrW86a4cWxMOvWn mLyg== MIME-Version: 1.0 X-Received: by 10.152.206.41 with SMTP id ll9mr28825719lac.103.1439328003481; Tue, 11 Aug 2015 14:20:03 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 11 Aug 2015 14:20:03 -0700 (PDT) In-Reply-To: <87a8txg7dz.fsf_-_@vigenere.g10code.de> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87a8txg7dz.fsf_-_@vigenere.g10code.de> Date: Tue, 11 Aug 2015 17:20:03 -0400 X-Google-Sender-Auth: R-YkNnNuFEnTTlbJNs4hj3joJQ0 Message-ID: From: Phillip Hallam-Baker To: Phillip Hallam-Baker , Peter Gutmann , IETF OpenPGP , Derek Atkins , ianG Content-Type: multipart/alternative; boundary=001a1133af6a5ce85a051d0faaed Archived-At: Subject: Re: [openpgp] Why or why not SHA{2, 3}-512 (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 21:22:14 -0000 --001a1133af6a5ce85a051d0faaed Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 11:41 AM, Werner Koch wrote: > On Tue, 11 Aug 2015 16:16, phill@hallambaker.com said: > > > every option. If you are going to sign a 1Gb file then you are going to > > need multiple trips through the digest function. Now there is of course a > > This is not an option for OpenPGP! OpenPGP has been carefully designed > to allow its use in a pipe ("online" in current parlance). Any signing > function which requires multiple passes over the signed data is useless. > (I heard of encrypted(+signed) backups in the TiB range.) That isn't what I was referring to, the signature mechanisms are using the digests internally. So the 1Gb file will go through once. But the proof of correctness for the signature algorithm itself requires internal digest functions. --001a1133af6a5ce85a051d0faaed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 11, 2015 at 11:41 AM, Werner Koch <wk@gnupg.org> = wrote:
On Tue, 11 Aug 2015 16:16, phill@hallambaker.com said:

> every option. If you are going to sign a 1Gb file then you are going t= o
> need multiple trips through the digest function. Now there is of cours= e a

This is not an option for OpenPGP!=C2=A0 OpenPGP has been carefully designe= d
to allow its use in a pipe ("online" in current parlance).=C2=A0 = Any signing
function which requires multiple passes over the signed data is useless. (I heard of encrypted(+signed) backups in the TiB range.)
=
That isn't what I was referring to, the signature mechan= isms are using the digests internally. So the 1Gb file will go through once= . But the proof of correctness for the signature algorithm itself requires = internal digest functions.

=C2=A0

<= /div>
--001a1133af6a5ce85a051d0faaed-- From nobody Tue Aug 11 19:08:38 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16FE1A1B64 for ; Tue, 11 Aug 2015 19:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EHrdTpg_mmb3 for ; Tue, 11 Aug 2015 19:08:36 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328961A1B39 for ; Tue, 11 Aug 2015 19:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439345316; x=1470881316; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iyfcvxUPYDJpWC8s+R9LG/Flnagyaw+92PGzHHyjGxE=; b=pvUonedrfdWWbC0j23VEavGGIQin9VCZ1GEEZrrziH3eCRwQo6RoQ41K KpVSZq2DyhdrBnA0aGBGlhl0+Zqn+ioCmbBbZ2bvUQndHUjJh0eJBjaEq df/hLKHM6PqS5uy2iCs/86bm1+/Wr1BZD+5lfluHfbq3BdVvhJMHY4UAa SBkL8cS6sXpzV0nHaHliv4TJWW85OaBnA2GNaB6xFCi6zCKlqvZgMWghn FYVG+RjkaaqYfGPxnPD2ABkOzv8u132jsCJju83J+44DsE2tS/ragdIBX 6XWiLKWrn4vGInQ3XT4QStO3YctiXfdWUcdtFebydk0O8F7jdmjVXDYjd A==; X-IronPort-AV: E=Sophos;i="5.15,657,1432555200"; d="scan'208";a="34537470" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Aug 2015 14:08:35 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 12 Aug 2015 14:08:34 +1200 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] SHA-x performance Thread-Index: AQHQ1HVJQ9dFbQGKcEKa6BiYPQDA/J4HnlTQ Date: Wed, 12 Aug 2015 02:08:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz>, <878u9hefcs.fsf@vigenere.g10code.de> In-Reply-To: <878u9hefcs.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF OpenPGP , Derek Atkins , Phillip Hallam-Baker , Daniel Kahn Gillmor , ianG Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 02:08:37 -0000 Werner Koch writes:=0A= =0A= >Do you have a suggestion on what CPUs from low to high end to do benchmark= s=0A= >so to check which SHA variant is suitable?=0A= =0A= It'd be a longish list :-). I'm also not sure how easy it'll be to get at= =0A= them, this is all embedded-systems stuff so you can't just SSH into a box a= nd=0A= run the tests. In any case the most common is ARM Cortex M (and a few R), = so=0A= any Cortex M3 (the example I gave was an STM32 at 180MHz which admittedly i= s=0A= the top end of the range, 100 or 80 Mhz would be another benchmark level, b= ut=0A= then they're all ARMv7-M so you can extrapolate from one clock speed to=0A= another), then for PowerPC something like an MPC560x at 80 MHz (very common= in=0A= industrial and automotive), a PIC32MX (MIPS32) at 60 MHz, and then for exot= ica=0A= maybe a NIOS II or MicroBlaze at 100 Mhz. You don't really need to do doze= ns=0A= of variants since things mostly scale directly with clock speed, and in any= =0A= case those are reasonably representative clocks, at least for the faster de= vices=0A= where power-saving isn't an issue.=0A= =0A= Peter.= From nobody Tue Aug 11 23:25:39 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AFF1B2B91 for ; Tue, 11 Aug 2015 23:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 LauFyAohYAp7 for ; Tue, 11 Aug 2015 23:25:35 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEADD1B2B87 for ; Tue, 11 Aug 2015 23:25:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZPPTg-0001oa-7z for ; Wed, 12 Aug 2015 08:25:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZPPQ3-0004AB-7H; Wed, 12 Aug 2015 08:21:47 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87a8txg7dz.fsf_-_@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , Peter Gutmann , IETF OpenPGP , Derek Atkins , ianG Date: Wed, 12 Aug 2015 08:21:46 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 11 Aug 2015 17:20:03 -0400") Message-ID: <87vbclc9hh.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG , Peter Gutmann Subject: Re: [openpgp] Why or why not SHA{2, 3}-512 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 06:25:37 -0000 On Tue, 11 Aug 2015 23:20, phill@hallambaker.com said: > That isn't what I was referring to, the signature mechanisms are using the > digests internally. So the 1Gb file will go through once. But the proof of > correctness for the signature algorithm itself requires internal digest I know. The speed of the hash algorithm is not an issue here, though. The only issue would be whether the extra code size required for a different hash algorithm than for what is used as part of the signature algorithm (SHA-256 for bulk, SHA-512 for EdDSA) is a matter of concern. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Aug 12 06:24:01 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B517A1B2D7E for ; Wed, 12 Aug 2015 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 hzX1CUgULiiQ for ; Wed, 12 Aug 2015 06:23:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6652F1A8993 for ; Wed, 12 Aug 2015 06:23:57 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id BBCDC6D76F; Wed, 12 Aug 2015 09:23:55 -0400 (EDT) Message-ID: <55CB48EB.5090403@iang.org> Date: Wed, 12 Aug 2015 14:23:55 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz>, <878u9hefcs.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 13:23:59 -0000 On 12/08/2015 03:08 am, Peter Gutmann wrote: > Werner Koch writes: > >> Do you have a suggestion on what CPUs from low to high end to do benchmarks >> so to check which SHA variant is suitable? > > It'd be a longish list :-). I'm also not sure how easy it'll be to get at > them, this is all embedded-systems stuff so you can't just SSH into a box and > run the tests. In any case the most common is ARM Cortex M (and a few R), so > any Cortex M3 (the example I gave was an STM32 at 180MHz which admittedly is > the top end of the range, 100 or 80 Mhz would be another benchmark level, but > then they're all ARMv7-M so you can extrapolate from one clock speed to > another), then for PowerPC something like an MPC560x at 80 MHz (very common in > industrial and automotive), a PIC32MX (MIPS32) at 60 MHz, and then for exotica > maybe a NIOS II or MicroBlaze at 100 Mhz. You don't really need to do dozens > of variants since things mostly scale directly with clock speed, and in any > case those are reasonably representative clocks, at least for the faster devices > where power-saving isn't an issue. To what extent are we accepting the embedded market as "our market" ? Is this something that already exists in the sense that a lot of them are already doing OpenPGP signing for some purpose? Is the process things like signed updates, or are people using OpenPGP to encrypt and/or sign requests to the devices? Or, are we making a stab at the future: "IoT will need security systems, and OpenPGP will be used to supply that, so we'd better make sure it fits on the rough template of devices." To give a ludicrous counter-example, we could also optimise the future hash for smartcards. That's another big market, why not? I'd say this doesn't work mostly because the smartcard or tokens market is mostly closed, and systems are typically constructed to be tightly bound to the end-user application; generic systems such as OpenPGP would find it hard. Where do we draw the line? Are embedded / IoT inside? iang From nobody Wed Aug 12 07:13:08 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE41A88ED for ; Wed, 12 Aug 2015 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 3xm800ra6YXa for ; Wed, 12 Aug 2015 07:13:04 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 40BF51A88A0 for ; Wed, 12 Aug 2015 07:13:04 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so10312376lbb.1 for ; Wed, 12 Aug 2015 07:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h2plnMzmEP9tVf/XTW+0Qu4YIBxEgnFs+TlXmrmtQrA=; b=TEDVbAoTYPsUSZ0DaD9M16FZgNzxNNK5diumpPSM1pDJkdhBsRdZrLTs5I3rgf4kDt 3mcLukOOMsoPnEgcji5QjDaO/O/tl7SGA1wf2PwNnPPWAlO3eT/1l/NZsksicb1PcAJb Doz7Z9VuuZoc+94FkUPSVRlypOj7T1lHmTgZdaaL5QluDmXK4obeqXcbd+k+bCW1GzNp 8+EQTdyabaNc4Fl9105omDNIifGrjKhU9rnPjaOYYPB3o9zNOo8+VJ1FZi+bI1DFnb+d 0alJoFfnyaWX5UxjR7V7N0Yk/5RKiixHaf4hloG2SNAfbNocES1SeOsHfzOvSuweggsc uNWA== MIME-Version: 1.0 X-Received: by 10.112.65.35 with SMTP id u3mr32060800lbs.103.1439388782748; Wed, 12 Aug 2015 07:13:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 12 Aug 2015 07:13:02 -0700 (PDT) In-Reply-To: <55CB48EB.5090403@iang.org> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> <878u9hefcs.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz> <55CB48EB.5090403@iang.org> Date: Wed, 12 Aug 2015 10:13:02 -0400 X-Google-Sender-Auth: jj4khvVlnW5ID7Uhye0K0Qlt59E Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: multipart/alternative; boundary=001a1134a09616ea11051d1dd1ac Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 14:13:06 -0000 --001a1134a09616ea11051d1dd1ac Content-Type: text/plain; charset=UTF-8 On Wed, Aug 12, 2015 at 9:23 AM, ianG wrote: > On 12/08/2015 03:08 am, Peter Gutmann wrote: > >> Werner Koch writes: >> >> Do you have a suggestion on what CPUs from low to high end to do >>> benchmarks >>> so to check which SHA variant is suitable? >>> >> >> It'd be a longish list :-). I'm also not sure how easy it'll be to get at >> them, this is all embedded-systems stuff so you can't just SSH into a box >> and >> run the tests. In any case the most common is ARM Cortex M (and a few >> R), so >> any Cortex M3 (the example I gave was an STM32 at 180MHz which admittedly >> is >> the top end of the range, 100 or 80 Mhz would be another benchmark level, >> but >> then they're all ARMv7-M so you can extrapolate from one clock speed to >> another), then for PowerPC something like an MPC560x at 80 MHz (very >> common in >> industrial and automotive), a PIC32MX (MIPS32) at 60 MHz, and then for >> exotica >> maybe a NIOS II or MicroBlaze at 100 Mhz. You don't really need to do >> dozens >> of variants since things mostly scale directly with clock speed, and in >> any >> case those are reasonably representative clocks, at least for the faster >> devices >> where power-saving isn't an issue. >> > > > To what extent are we accepting the embedded market as "our market" ? > > Is this something that already exists in the sense that a lot of them are > already doing OpenPGP signing for some purpose? Is the process things like > signed updates, or are people using OpenPGP to encrypt and/or sign requests > to the devices? > > Or, are we making a stab at the future: "IoT will need security systems, > and OpenPGP will be used to supply that, so we'd better make sure it fits > on the rough template of devices." > > To give a ludicrous counter-example, we could also optimise the future > hash for smartcards. That's another big market, why not? I'd say this > doesn't work mostly because the smartcard or tokens market is mostly > closed, and systems are typically constructed to be tightly bound to the > end-user application; generic systems such as OpenPGP would find it hard. > > Where do we draw the line? Are embedded / IoT inside? If we are picking algorithm suites then we should look at the cases where the choice might matter rather than when it does not. IOT looks set to create a demand for an absolutely minimal cryptographic suite. One signature algorithm, one exchange algorithm, both on the same curve, one authenticated encryption mode, one digest/pseudorandom function. That suite is going to be the one that finds its way into hardware accelerators and those are in turn the sort of things that are going to be found as standard cell and on smartcards and such. So looking at a five year horizon, that is the set that is interesting. --001a1134a09616ea11051d1dd1ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 12, 2015 at 9:23 AM, ianG <iang@iang.org> wrote:=
On 12/08/2015 03:08 am,= Peter Gutmann wrote:
Werner Koch <wk@gnupg.= org> writes:

Do you have a suggestion on what CPUs from low to high end to do benchmarks=
so to check which SHA variant is suitable?

It'd be a longish list :-).=C2=A0 I'm also not sure how easy it'= ;ll be to get at
them, this is all embedded-systems stuff so you can't just SSH into a b= ox and
run the tests.=C2=A0 In any case the most common is ARM Cortex M (and a few= R), so
any Cortex M3 (the example I gave was an STM32 at 180MHz which admittedly i= s
the top end of the range, 100 or 80 Mhz would be another benchmark level, b= ut
then they're all ARMv7-M so you can extrapolate from one clock speed to=
another), then for PowerPC something like an MPC560x at 80 MHz (very common= in
industrial and automotive), a PIC32MX (MIPS32) at 60 MHz, and then for exot= ica
maybe a NIOS II or MicroBlaze at 100 Mhz.=C2=A0 You don't really need t= o do dozens
of variants since things mostly scale directly with clock speed, and in any=
case those are reasonably representative clocks, at least for the faster de= vices
where power-saving isn't an issue.


 To what extent are we accepting the embedded market as "our market&quo= t; ?

Is this something that already exists in the sense that a lot of them are a= lready doing OpenPGP signing for some purpose?=C2=A0 Is the process things = like signed updates, or are people using OpenPGP to encrypt and/or sign req= uests to the devices?

Or, are we making a stab at the future:=C2=A0 "IoT will need security = systems, and OpenPGP will be used to supply that, so we'd better make s= ure it fits on the rough template of devices."

To give a ludicrous counter-example, we could also optimise the future hash= for smartcards.=C2=A0 That's another big market, why not?=C2=A0 I'= d say this doesn't work mostly because the smartcard or tokens market i= s mostly closed, and systems are typically constructed to be tightly bound = to the end-user application;=C2=A0 generic systems such as OpenPGP would fi= nd it hard.

Where do we draw the line?=C2=A0 Are embedded / IoT inside?

If we are picking algorithm suites then we should look at = the cases where the choice might matter rather than when it does not.
=

IOT looks set to create a demand for an absolutely mini= mal cryptographic suite. One signature algorithm, one exchange algorithm, b= oth on the same curve, one authenticated encryption mode, one digest/pseudo= random function.=C2=A0

= That suite is going to be the one that finds its way into hardware accelera= tors and those are in turn the sort of things that are going to be found as= standard cell and on smartcards and such.
=
So looking at a five year horizon, tha= t is the set that is interesting.
--001a1134a09616ea11051d1dd1ac-- From nobody Wed Aug 12 07:41:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59561A897C for ; Wed, 12 Aug 2015 07:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 EKYF4mU8ZepA for ; Wed, 12 Aug 2015 07:40:58 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2011A8973 for ; Wed, 12 Aug 2015 07:40:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5B528E2036; Wed, 12 Aug 2015 10:40:56 -0400 (EDT) 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 23794-02; Wed, 12 Aug 2015 10:40:53 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 58EC7E2034; Wed, 12 Aug 2015 10:40:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1439390453; bh=z+k4UvzfTGDrqh7F6ioqMFUVjxOllD0Ihs1XjFFICW8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=lE6GNJ9RS0jzIIA45sshqBIhy0Hr50v9VHwwSY2o/+7Tx60fTrUYgHm6pLg8Sbpu8 datbOSgVSYkubzTr458pBhkqJUGV1bHEX9FV5ckdXsn+m4pAX8SsLADCbGFexJWkIp mCOQwxnfU9lvyUEV3h+yaTQujyY1JRxjuIrnTqr0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7CEeqdx017053; Wed, 12 Aug 2015 10:40:52 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 12 Aug 2015 10:40:52 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 11 Aug 2015 10:16:43 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG , Peter Gutmann Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 14:40:59 -0000 Phillip Hallam-Baker writes: > Constrained devices still exist. But the constraint on processing speed is > easing up much more quickly than the constraint on code space and working > memory. You'd actually be surprised at how untrue this is. There are tons of devices out there still using 8- and 16-bit processors (or no processors at all!) What's happening is that these low-end systems are getting installed into smaller and smaller devices. So yes, if you look at a particular device (e.g. cell phone) it's getting more powerful every year. However soon our light bulbs will be "smart". So let's not assume that these low-end processors are going away, please? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 12 08:11:48 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425F31A8A47 for ; Wed, 12 Aug 2015 08:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1DNhjVJ_HlfR for ; Wed, 12 Aug 2015 08:11:45 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6FB1A8A45 for ; Wed, 12 Aug 2015 08:11:45 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 83D9E6D75C; Wed, 12 Aug 2015 11:11:44 -0400 (EDT) Message-ID: <55CB6230.1050508@iang.org> Date: Wed, 12 Aug 2015 16:11:44 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> <878u9hefcs.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz> <55CB48EB.5090403@iang.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 15:11:47 -0000 On 12/08/2015 15:13 pm, Phillip Hallam-Baker wrote: > > > On Wed, Aug 12, 2015 at 9:23 AM, ianG > wrote: > > On 12/08/2015 03:08 am, Peter Gutmann wrote: > > Werner Koch > writes: > > Do you have a suggestion on what CPUs from low to high end > to do benchmarks > so to check which SHA variant is suitable? > > > It'd be a longish list :-). I'm also not sure how easy it'll be > to get at > them, this is all embedded-systems stuff so you can't just SSH > into a box and > run the tests. In any case the most common is ARM Cortex M (and > a few R), so > any Cortex M3 (the example I gave was an STM32 at 180MHz which > admittedly is > the top end of the range, 100 or 80 Mhz would be another > benchmark level, but > then they're all ARMv7-M so you can extrapolate from one clock > speed to > another), then for PowerPC something like an MPC560x at 80 MHz > (very common in > industrial and automotive), a PIC32MX (MIPS32) at 60 MHz, and > then for exotica > maybe a NIOS II or MicroBlaze at 100 Mhz. You don't really need > to do dozens > of variants since things mostly scale directly with clock speed, > and in any > case those are reasonably representative clocks, at least for > the faster devices > where power-saving isn't an issue. > > > > To what extent are we accepting the embedded market as "our market" ? > > Is this something that already exists in the sense that a lot of > them are already doing OpenPGP signing for some purpose? Is the > process things like signed updates, or are people using OpenPGP to > encrypt and/or sign requests to the devices? > > Or, are we making a stab at the future: "IoT will need security > systems, and OpenPGP will be used to supply that, so we'd better > make sure it fits on the rough template of devices." > > To give a ludicrous counter-example, we could also optimise the > future hash for smartcards. That's another big market, why not? > I'd say this doesn't work mostly because the smartcard or tokens > market is mostly closed, and systems are typically constructed to be > tightly bound to the end-user application; generic systems such as > OpenPGP would find it hard. > > Where do we draw the line? Are embedded / IoT inside? > > > If we are picking algorithm suites then we should look at the cases > where the choice might matter rather than when it does not. > > IOT looks set to create a demand for an absolutely minimal cryptographic > suite. One signature algorithm, one exchange algorithm, both on the same > curve, one authenticated encryption mode, one digest/pseudorandom function. > > That suite is going to be the one that finds its way into hardware > accelerators and those are in turn the sort of things that are going to > be found as standard cell and on smartcards and such. > > So looking at a five year horizon, that is the set that is interesting. Yes I entirely agree, that interesting discussion exists. Is that what we are doing here, though? Are we rewriting OpenPGP so we can turn on the lightbulb? Personally, I see a huge leap here. OpenPGP isn't suitable/designed at all for that application(s) / market(s). iang From nobody Wed Aug 12 08:42:56 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9561A8AA1 for ; Wed, 12 Aug 2015 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 GKFW23ytH7Aj for ; Wed, 12 Aug 2015 08:42:53 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 5DB8D1A8748 for ; Wed, 12 Aug 2015 08:42:53 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so11769265lbc.2 for ; Wed, 12 Aug 2015 08:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Xc/tid/Fk/ScqqP48Ix3iWPmW890lgBB8Df6bSZBcfE=; b=g4hd2qI71nB5SRnQx9SNPx/+BlxquA1q7r6l9pXAIHB/wpiRI5pXndXiSOzGjJDBJF AqqnV01L/A+aMX18/4MGIV/oSuUUVQIpokzfCm541jGcuxeFUz+ZM+/QNpohkj8IfQr/ iEiNaBy63JMBbvqUIYxE95VyYX5YeBx9QsjHWTatGoDEPS9eYZ2tifA8g+ZyunUkCq8+ ah6PFPcjcIIxvGVURCdAC0X4dz+wvKO+pmeqC59+CGpG/rSUGAVk49xQxNN43nHaQqLc n4ueAaVQ8alCx542n2mOHT9xC9HKpD8GzPfDyYYsY1WLQiUCVkOay4dpEPkh/iT+R5Z7 uFXw== MIME-Version: 1.0 X-Received: by 10.152.204.196 with SMTP id la4mr32824594lac.124.1439394171754; Wed, 12 Aug 2015 08:42:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 12 Aug 2015 08:42:51 -0700 (PDT) In-Reply-To: References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 12 Aug 2015 11:42:51 -0400 X-Google-Sender-Auth: GhY36Ik0UX026bOtvOqYevTkxE8 Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a113499ce4ca147051d1f1294 Archived-At: Cc: IETF OpenPGP , ianG , Peter Gutmann Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 15:42:55 -0000 --001a113499ce4ca147051d1f1294 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 12, 2015 at 10:40 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > > > Constrained devices still exist. But the constraint on processing speed > is > > easing up much more quickly than the constraint on code space and working > > memory. > > You'd actually be surprised at how untrue this is. There are tons of > devices out there still using 8- and 16-bit processors (or no processors > at all!) What's happening is that these low-end systems are getting > installed into smaller and smaller devices. So yes, if you look at a > particular device (e.g. cell phone) it's getting more powerful every > year. However soon our light bulbs will be "smart". > > So let's not assume that these low-end processors are going away, please? Well the constraint on processing is easing up due to the move from RSA to ECC. And for the amount of data going though one of these processors, the choice of AES or DES doesn't make much of a difference. These things don't have to communicate very fast. The thing that gets really uncomfortable is dealing with the amount of memory available. Quite a few of the embedded chips have even less RAM than the Commodore PET I started with when 32KB was the large machine. Yes, these chips are not going away any time soon. The number of chips being made with 6502 based cores has increased every year since the 80s. But the problem with the chips isn't just that they are slow. --001a113499ce4ca147051d1f1294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 12, 2015 at 10:40 AM, Derek Atkins <derek@ihtfp.com><= /span> wrote:
Phillip Ha= llam-Baker <phill@hallambaker.c= om> writes:

> Constrained devices still exist. But the constraint on processing spee= d is
> easing up much more quickly than the constraint on code space and work= ing
> memory.

You'd actually be surprised at how untrue this is.=C2=A0 There a= re tons of
devices out there still using 8- and 16-bit processors (or no processors at all!)=C2=A0 What's happening is that these low-end systems are getti= ng
installed into smaller and smaller devices.=C2=A0 So yes, if you look at a<= br> particular device (e.g. cell phone) it's getting more powerful every year.=C2=A0 However soon our light bulbs will be "smart".

So let's not assume that these low-end processors are going away, pleas= e?

Well the constraint on processing is eas= ing up due to the move from RSA to ECC. And for the amount of data going th= ough one of these processors, the choice of AES or DES doesn't make muc= h of a difference. These things don't have to communicate very fast.

The thing that gets really uncomfortable is dealing = with the amount of memory available. Quite a few of the embedded chips have= even less RAM than the Commodore PET I started with when 32KB was the larg= e machine.=C2=A0

Yes, these= chips are not going away any time soon. The number of chips being made wit= h 6502 based cores has increased every year since the 80s. But the problem = with the chips isn't just that they are slow.
--001a113499ce4ca147051d1f1294-- From nobody Wed Aug 12 10:12:26 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD201A90EB for ; Wed, 12 Aug 2015 10:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 PihYSVnplzXT for ; Wed, 12 Aug 2015 10:12:22 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id A50561A9154 for ; Wed, 12 Aug 2015 10:12:20 -0700 (PDT) Received: from [70.192.23.3] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZPZZV-0002yL-9e; Wed, 12 Aug 2015 13:12:13 -0400 Date: Wed, 12 Aug 2015 10:12:12 -0700 From: Bill Frantz To: ianG X-Priority: 3 In-Reply-To: <55CB6230.1050508@iang.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79f3e5db707464f9bc8ec3279cae4fc5c3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 70.192.23.3 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 17:12:24 -0000 On 8/12/15 at 8:11 AM, iang@iang.org (ianG) wrote: >Personally, I see a huge leap here. OpenPGP isn't=20 >suitable/designed at all for that application(s) / market(s). I see some security needs in this market that, like most=20 security needs, are being generally ignored. (1) Authentication of messages (2) Replay protection for messages (3) Authentication of software updates Can PGP perform these functions? Is it the best technical solution? If the answer to both of these is yes, then we should consider=20 these small systems. Cheers - Bill ------------------------------------------------------------------------ Bill Frantz |"Insofar as the propositions of mathematics=20 refer to 408-356-8506 | reality, they are not certain; and insofar=20 they are www.pwpconsult.com | certain, they do not refer to reality.=E2=80=9D=20 -- Einstein From nobody Wed Aug 12 10:39:01 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40C31A92EE for ; Wed, 12 Aug 2015 10:39:00 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 i9vlzIvBZqla for ; Wed, 12 Aug 2015 10:38:59 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F01F1A92E5 for ; Wed, 12 Aug 2015 10:38:59 -0700 (PDT) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZPZzO-0000SJ-Bo; Wed, 12 Aug 2015 11:38:58 -0600 Received: from mta2.zcs.xmission.com ([166.70.13.66]) by mx02.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1ZPZzN-0006Dc-DK; Wed, 12 Aug 2015 11:38:57 -0600 Received: from localhost (localhost [127.0.0.1]) by mta2.zcs.xmission.com (Postfix) with ESMTP id 145486001C1; Wed, 12 Aug 2015 11:38:57 -0600 (MDT) Received: from mta2.zcs.xmission.com ([127.0.0.1]) by localhost (mta2.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p4fIJaID1Mhh; Wed, 12 Aug 2015 11:38:57 -0600 (MDT) Received: from zms04.zcs.xmission.com (zms04.zcs.xmission.com [166.70.13.74]) by mta2.zcs.xmission.com (Postfix) with ESMTP id 00E676001BF; Wed, 12 Aug 2015 11:38:57 -0600 (MDT) Date: Wed, 12 Aug 2015 11:38:56 -0600 (MDT) From: Hilarie Orman To: Bill Frantz Message-ID: <1451253004.21291912.1439401136539.JavaMail.zimbra@purplestreak.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [72.250.219.84] X-Mailer: Zimbra 8.6.0_GA_1178 (zclient/8.6.0_GA_1178) Thread-Topic: SHA-x performance Thread-Index: GHYR+IFd01mvC5Ak40d2HMq8iV3LWQ== X-SA-Exim-Connect-IP: 166.70.13.66 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Bill Frantz X-Spam-Relay-Country: XX X-Spam-Timing: total 484 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.8 (1.0%), b_tie_ro: 3.7 (0.8%), parse: 1.43 (0.3%), extract_message_metadata: 41 (8.4%), get_uri_detail_list: 3.0 (0.6%), tests_pri_-1000: 13 (2.6%), tests_pri_-950: 1.57 (0.3%), tests_pri_-900: 1.64 (0.3%), tests_pri_-400: 40 (8.3%), check_bayes: 38 (7.9%), b_tokenize: 11 (2.2%), b_tok_get_all: 7 (1.5%), b_comp_prob: 4.1 (0.8%), b_tok_touch_all: 12 (2.5%), b_finish: 1.07 (0.2%), tests_pri_0: 352 (72.7%), tests_pri_500: 15 (3.0%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:24:12 -0600) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Archived-At: Cc: openpgp@ietf.org, ianG Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 17:39:00 -0000 For the very low end devices, things that run on a AA battery for 10 years unattended, there simply is not enough power to do any kind of crypto. It's a research problem for device physicists. Hilarie ----- Original Message ----- From: Bill Frantz To: ianG Cc: openpgp@ietf.org Sent: Wed, 12 Aug 2015 11:12:12 -0600 (MDT) Subject: Re: [openpgp] SHA-x performance On 8/12/15 at 8:11 AM, iang@iang.org (ianG) wrote: >Personally, I see a huge leap here. OpenPGP isn't=20 >suitable/designed at all for that application(s) / market(s). I see some security needs in this market that, like most=20 security needs, are being generally ignored. (1) Authentication of messages (2) Replay protection for messages (3) Authentication of software updates Can PGP perform these functions? Is it the best technical solution? If the answer to both of these is yes, then we should consider=20 these small systems. Cheers - Bill ------------------------------------------------------------------------ Bill Frantz |"Insofar as the propositions of mathematics=20 refer to 408-356-8506 | reality, they are not certain; and insofar=20 they are www.pwpconsult.com | certain, they do not refer to reality.=E2=80=9D=20 -- Einstein _______________________________________________ openpgp mailing list openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp From nobody Wed Aug 12 13:05:40 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BC71ACD81 for ; Wed, 12 Aug 2015 13:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 J-U1OSYjxfHx for ; Wed, 12 Aug 2015 13:05:38 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 E0F531ACD83 for ; Wed, 12 Aug 2015 13:05:37 -0700 (PDT) Received: by lagz9 with SMTP id z9so15209440lag.3 for ; Wed, 12 Aug 2015 13:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=M9FcycAuFj5AYApCKYFc48PyRMS9S9YV2mqnCPLf6hM=; b=kcmpA5tjcsHlffcuH6/L9lACXho7qVfZUqplxxNeish04nThqkYrQHwU7akXqFvwX9 D2LtJwOTiHuqxQZ+L9jc77h+3IVMcdsF1Z7DdmYkU16pzbBuOe5/klB0LasIWwbd68GJ xP9TyE62L9XZZwcw+b9/sV7Li01Nti+zhwSkzWnB6SpxokbTfnpOuizEIKXvcZZe06+D dNpYZSYniB4zT2eezDpzAkAC9TVsE4wFzV9ktFkSAdCvN3EFCw8Sp1FGFTUESYoSftQ6 XmrQyNd0wRczGKmZ3Jtbdv/19E0iH2RbIgaiIm5e+//hRFqm7PtJ+/BXg/LQL7O49r2w Actg== MIME-Version: 1.0 X-Received: by 10.152.178.229 with SMTP id db5mr34102956lac.55.1439409936366; Wed, 12 Aug 2015 13:05:36 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 12 Aug 2015 13:05:36 -0700 (PDT) In-Reply-To: <87614lg72t.fsf_-_@vigenere.g10code.de> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87614lg72t.fsf_-_@vigenere.g10code.de> Date: Wed, 12 Aug 2015 16:05:36 -0400 X-Google-Sender-Auth: 2FbrZH_hSArKkRnOyZ83WrNK22U Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann , Phillip Hallam-Baker , Derek Atkins , IETF OpenPGP , ianG Content-Type: multipart/alternative; boundary=001a113415eaf183a8051d22bdc4 Archived-At: Subject: Re: [openpgp] WWhy or why not SHA{2, 3}-512 (was: SHA3 algorithm ids) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 20:05:39 -0000 --001a113415eaf183a8051d22bdc4 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 11:47 AM, Werner Koch wrote: > On Tue, 11 Aug 2015 15:21, pgut001@cs.auckland.ac.nz said: > > > What's the clear need for -512? By which I mean a demonstrated > practical need > > for a hash size of 64 bytes, not a hypothesised need given an imaginary > > attack. I can see a need for SHA-256 (to replace SHA-1), but for > something > > like SHA3-512 all I can see are downsides (compared to SHA2-256). > > One advantage of SHA-512 (SHA2) is that it faster than SHA-256 on modern > machines. Thus SHA-512 truncated to 256 might be an option. This would > eventually allow to write a small application which uses SHA-512 as its > only hash algorithm. > Yes, oddly enough, this is a case where the pressure seems to be behind 512 being the default strength. We definitely need 512 bits and adding 256 in addition seems like its the thing to do. While the CFRG crypto is going for the 512 bit hash internally, there is still a lot of ECDSA based stuff using the NIST curves and that expects the 256 bit digest. I can't see any particular reason for any of the other key strengths. Talking of constrained devices BTW, I'm just trying out the new Windows 10 on a Raspberry Pi 2. Of course its going to have all the NIST curve generation ECC and we are likely 3 years off the point where the CFRG stuff is ubiquitous. --001a113415eaf183a8051d22bdc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 11, 2015 at 11:47 AM, Werner Koch <wk@gnupg.org> = wrote:
On Tue, 11 Aug 2015 15:21, pgut001@cs.auckland.ac.nz said:
> What's the clear need for -512?=C2=A0 By which I mean a demonstrat= ed practical need
> for a hash size of 64 bytes, not a hypothesised need given an imaginar= y
> attack.=C2=A0 I can see a need for SHA-256 (to replace SHA-1), but for= something
> like SHA3-512 all I can see are downsides (compared to SHA2-256).

One advantage of SHA-512 (SHA2) is that it faster than SHA-256 on modern machines.=C2=A0 Thus SHA-512 truncated to 256 might be an option.=C2=A0 Thi= s would
eventually allow to write a small application which uses SHA-512 as its
only hash algorithm.

Yes, oddly enough,= this is a case where the pressure seems to be behind 512 being the default= strength.

We definitely need 512 bits and adding = 256 in addition seems like its the thing to do. While the CFRG crypto is go= ing for the 512 bit hash internally, there is still a lot of ECDSA based st= uff using the NIST curves and that expects the 256 bit digest.=C2=A0
<= div>
I can't see any particular reason for any of the oth= er key strengths.


Talking of constr= ained devices BTW, I'm just trying out the new Windows 10 on a Raspberr= y Pi 2. Of course its going to have all the NIST curve generation ECC and w= e are likely 3 years off the point where the CFRG stuff is ubiquitous.
--001a113415eaf183a8051d22bdc4-- From nobody Wed Aug 12 16:15:56 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33E31B2A01 for ; Wed, 12 Aug 2015 16:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uXlE5ZGMza5E for ; Wed, 12 Aug 2015 16:15:53 -0700 (PDT) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF2A1B2A09 for ; Wed, 12 Aug 2015 16:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=b90yIU3j3GRnbKry02ppDSdObdoOUERUGTxHDKci2Q4=; b=LXg1qjOw+d0Q+YKfI/2uBydnxJw+sB+YF9GhsOB27jcE8WdHbIAJ8g/BRopgQiyYI4S9BEkLzhPBwRqfDy1aRyzbeHdfkKcPICTZDUsma8lgyrPiJlnUXLKFlibnX9p1ekIg6Drwe2Olw8MD4x/koe3pwOWvemg0v1LqA8oWWI6Y/1873el9thxKN6GHLOdpYfydDEbRZhEUoGwai/Mt0sOQUaEV5pylFGA/W0KjmQYnW1tqX9c15n+YBWTT9IYVKYZV5temCvfFjJulasLfLStZroLKc+H21GxHeJd2lCs7I60c2QoKaUmAplSQHsXrR9yfwnRz3voNQBCpOnOcSg==; Received: from e139117.dynamic.ppp.asahi-net.or.jp ([211.13.139.117] helo=[192.168.23.212]) by akagi.fsij.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZPfDg-0000nq-TI; Thu, 13 Aug 2015 08:14:05 +0900 Message-ID: <55CBD398.5010905@fsij.org> Date: Thu, 13 Aug 2015 08:15:36 +0900 From: NIIBE Yutaka Organization: Free Software Initiative of Japan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: wk@gnupg.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz> <878u9hefcs.fsf@vigenere.g10code.de> In-Reply-To: <878u9hefcs.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: IETF OpenPGP , Peter Gutmann , Phillip Hallam-Baker , Derek Atkins , Daniel Kahn Gillmor , ianG Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 23:15:55 -0000 On 08/12/2015 05:32 AM, Werner Koch wrote: > Do you have a suggestion on what CPUs from low to high end to do > benchmarks so to check which SHA variant is suitable? FWIW, here is some fact. My RSA-2048 private key is on FST-01, which uses STM32F103 @ 72MHz. This device is used to sign GnuPG source code release. And it's daily use to my access to Git repositories by OpenSSH. With no crypto accelerator, it takes about 1.4 second to sign. Yesterday, I created a new key of ed25519/cv25519 and installed on another FST-01. It's faster. If a user can wait for EdDSA computation as long as computation of RSA-2048, STM32F030 @ 48MHz would be a candidate (no, I haven't tested yet, just a possibility). Please note that the firmware (Gnuk) doesn't implement OpenPGP, but only OpenPGPcard specification. It only computes with private key. Since EdDSA requires SHA2-512, we have SHA2-512. It scales to low end, when/if a user can wait. -- From nobody Wed Aug 12 17:24:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F881B2E6A for ; Wed, 12 Aug 2015 17:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4-z-nQTqGU7R for ; Wed, 12 Aug 2015 17:24:15 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0431B2E66 for ; Wed, 12 Aug 2015 17:24:15 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 6275011C16EE for ; Thu, 13 Aug 2015 10:24:13 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8uO64WNS75Pp for ; Thu, 13 Aug 2015 10:23:32 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 6696311C16EC for ; Thu, 13 Aug 2015 10:23:04 +1000 (EST) To: openpgp@ietf.org References: From: Ben McGinnes Message-ID: <55CBE357.4010800@adversary.org> Date: Thu, 13 Aug 2015 10:22:47 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vKCmdwfM1Dva3RQ7TAMi7SdD3v7kkcLm2" Archived-At: Subject: Re: [openpgp] Crypto on Rails X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 00:24:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vKCmdwfM1Dva3RQ7TAMi7SdD3v7kkcLm2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/07/2015 1:59 am, Phillip Hallam-Baker wrote: >=20 > If we can introduce a fingerprint format that can be used on any type o= f > input data without semantic substitution attacks, we can make interfaci= ng > OpenPGP to other types of cryptosystem a lot easier and simplify the > implementation and deployment of all types of crypto system. So, essentially applying the KISS principle to crypto instead of treating it like voodoo. Sounds good to me. Regards, Ben --vKCmdwfM1Dva3RQ7TAMi7SdD3v7kkcLm2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVy+NgAAoJEH/y03E1x1U86/8L+wRr73/zI7RMxGA0eC5Ml7rW hv2mH6GYObPlx1vI3PQBNLANlEgoBQZtLKe3kOzwrEn8kTiP2ylzN2ldLWDXTsAy fdMLXbWte1NojizFAwuyfUnNhYFNrHtoH68atwquARst2OWtkGZHzTZzp99fZIfU Yaoy10ooHy2C71AQaEtcnutlHV3xGWFNqhdjV+GiQNRRP5n2bl/ezDjMpQ2zmxYG xa8jsixhNEN6XQHBhCh0mPkEU4xRn9Ih5fu422bdCiCvw8Q3s54m8Unl3HC7rY40 gSl5O3EejuWZKbjnhkCu+kW02LlmzGWgi/sHLmfs8bGGzghmNQiTcydzLldJF5/h iyU1f6WQcmlUuzkxD1C2zYIWgK/bioAomnuVyIMo2c6SsOrN3xBnKUhkq3JvTXZ7 TiMpICXuynJKPTt60OtJrwDZA3x4W4Rl9MxSSYLY4id1QLCYIzqW1B0+LP0aXZKu GE3uiBUWUFgBgTtvs4+rPRUVrMD2eViq+u1sNjhWag== =buy0 -----END PGP SIGNATURE----- --vKCmdwfM1Dva3RQ7TAMi7SdD3v7kkcLm2-- From nobody Thu Aug 13 06:32:51 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6454E1A21AA for ; Thu, 13 Aug 2015 06:32:50 -0700 (PDT) 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] autolearn=ham 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 uw7Uc8J9QwoN for ; Thu, 13 Aug 2015 06:32:49 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143: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 CFD161A21A6 for ; Thu, 13 Aug 2015 06:32:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4A472E2036; Thu, 13 Aug 2015 09:32:47 -0400 (EDT) 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 31827-09; Thu, 13 Aug 2015 09:32:45 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::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 45E6BE2034; Thu, 13 Aug 2015 09:32:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1439472765; bh=tNtY2t0zPeZiUqiBURlhKQNvPyIm6tJUv2DQGmqUODw=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=i1I4riqpF+WaVqPrwY1199sGmygQ/sEK3fKERvp86lvvFAuodkJIqxdu61OkyS67W yJBsz229o7R1fYgUUAkOQzzhO9M/NYWBNdphdx6Jthti1gadRN39HXV5nvb5D40pWh 1lOvNAotaOSWpwuvh4d6qzSdkSTqfr8rSQazOX+c= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7DDWibG001737; Thu, 13 Aug 2015 09:32:44 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 13 Aug 2015 09:32:44 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 12 Aug 2015 11:42:51 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Derek Atkins , ianG , Peter Gutmann Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 13:32:50 -0000 Phillip Hallam-Baker writes: > So let's not assume that these low-end processors are going away, ple= ase? > > Well the constraint on processing is easing up due to the move from RSA t= o ECC. Sure, it reduces computation time from tens of seconds down to ones of seconds. ;) > And for the amount of data going though one of these processors, the choi= ce of > AES or DES doesn't make much of a difference. These things don't have to > communicate very fast. > > The thing that gets really uncomfortable is dealing with the amount of me= mory > available. Quite a few of the embedded chips have even less RAM than the > Commodore PET I started with when 32KB was the large machine.=C2=A0 Oh, yeah. Some of the environments I work in have like 2-4KB of RAM! > Yes, these chips are not going away any time soon. The number of chips be= ing > made with 6502 based cores has increased every year since the 80s. But the > problem with the chips isn't just that they are slow. I'm not seeing 6502, but I am seeing a lot of 8051. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Aug 14 02:30:36 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995BD1A710D for ; Fri, 14 Aug 2015 02:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oDiF-sc8Oini for ; Fri, 14 Aug 2015 02:30:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823451A7013 for ; Fri, 14 Aug 2015 02:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439544629; x=1471080629; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C+YN/S0NSvS6REaMNeesZJ4oS5+mbRSjqYxvZTGRrLI=; b=e/TrClhv3lm5Ugh6RC/RyjcknP68eL+8ZLvcRhprzxUXpEJduUU2jHGz qZZR1imRJZTBy04Eni+FMMvB91pTHGFHyoEy0EMBPGf7Vh13e6WbOU0O5 MK+YtEvLCCKpBPBD48OvqRfKiqBRPoNZHNe1qgedwBYOYk41bW1Y2XqxT /5bV+tpKDghk+4lE1EsZKVTCAlSi5Zh1APmG07JHg0tKIxhcwp3Uu1de3 7gZNJM7Ac3etoXB0SjvVDMP4IYXyDfbuL5uskIHYfaIe5OVMuEr9dOX0H jfoaWNtkG8Nmc4oRwj/2W1vXLdW3/PU4j8B3gzSAlM2Z7CoxP1ASrIF6C Q==; X-IronPort-AV: E=Sophos;i="5.15,676,1432555200"; d="scan'208";a="35122966" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Aug 2015 21:30:24 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 14 Aug 2015 21:30:24 +1200 From: Peter Gutmann To: ianG , "openpgp@ietf.org" Thread-Topic: [openpgp] SHA-x performance Thread-Index: AQHQ1HVJQ9dFbQGKcEKa6BiYPQDA/J4HnlTQ///z3YCAA6wbrg== Date: Fri, 14 Aug 2015 09:30:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4ADA96F@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> <87io8lpzu4.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4AD7F8E@uxcn10-5.UoA.auckland.ac.nz> <87mvxxenss.fsf_-_@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD8086@uxcn10-5.UoA.auckland.ac.nz>, <878u9hefcs.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4AD85CC@uxcn10-5.UoA.auckland.ac.nz>, <55CB48EB.5090403@iang.org> In-Reply-To: <55CB48EB.5090403@iang.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] SHA-x performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 09:30:34 -0000 ianG writes:=0A= =0A= >To what extent are we accepting the embedded market as "our market" ?=0A= =0A= It's not a case of "now we want to target 8051's" but more a case of "the s= ame=0A= hardware that can currently employ PGP shouldn't be prevented from employin= g=0A= it in the future because of a change to an overly heavyweight algorithm".= =0A= Switching from SHA-1 to SHA-256 isn't a big deal, but going to SHA-512 with= =0A= its order-of-magnitude slowdown over -256 is.=0A= =0A= An example of a typical target device was the one mentioned in another post= by=0A= Yutaka Niibe, an STM32F103, which is a Cortex M3 that I mentioned earlier. = A=0A= more recent, and also very popular one, is the M0 (released five years afte= r=0A= the M3, but with much more minimal capabilities, I'd set the minimum target= at=0A= an M3 in that if you want to be doing crypto you shouldn't be using an M0).= =0A= =0A= >Is this something that already exists in the sense that a lot of them are= =0A= >already doing OpenPGP signing for some purpose? =0A= =0A= Use of PGP in embedded is basically nonexistent, so it's more a case of "th= is=0A= could be useful in the future". The stuff will have to be secured in some= =0A= manner, and being able to present PGP as a candidate would be good.=0A= =0A= (To put this into perspective, there's an apparently neverending stream of= =0A= checkbox-engineered security standards and best-practices for things like= =0A= smart meters where the developers are being asked to implement X.509 cert= =0A= handling, SCEP for cert enrolment, TLS for reporting, and SSH for remote=0A= management, on an M0 realtime system (so no task can hold up the CPU for mo= re=0A= than, say, 10ms) with 4kB RAM and 32kB flash total. Now admittedly PGP won= 't=0A= fit into that either, but it's slightly less insane than the wishlists bein= g=0A= promulgated by industry groups. I have no idea what developers are doing i= n=0A= response to this disconnect from reality in the requirements, but I'm guess= ing=0A= it'll provide fodder for Black Hat and Defcon talks for years to come).=0A= =0A= Peter.=0A= From nobody Fri Aug 14 11:20:33 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2D1A0151 for ; Fri, 14 Aug 2015 11:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 hiKOuIevfu35 for ; Fri, 14 Aug 2015 11:20:29 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA721A0045 for ; Fri, 14 Aug 2015 11:20:29 -0700 (PDT) Received: from [174.236.7.135] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZQJa9-0004Iq-GY; Fri, 14 Aug 2015 14:19:58 -0400 Date: Fri, 14 Aug 2015 11:19:42 -0700 From: Bill Frantz To: Derek Atkins X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79e2552a9d008aa7614b81febf17159ab2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.236.7.135 Archived-At: Cc: Peter Gutmann , Phillip Hallam-Baker , ianG , IETF OpenPGP Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 18:20:31 -0000 On 8/13/15 at 6:32 AM, derek@ihtfp.com (Derek Atkins) wrote: >>Yes, these chips are not going away any time soon. The number of chips be= ing >>made with 6502 based cores has increased every year since the 80s. But th= e >>problem with the chips isn't just that they are slow. > >I'm not seeing 6502, but I am seeing a lot of 8051. I think in the IoT space, we will need to have signed software=20 updates. I don't think there is much of an issue taking several=20 seconds to verify an update signature, but these 8 bit=20 processors seem like the right level of hardware for these IoT devices. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345=20 Englewood Ave www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nobody Fri Aug 14 12:08:28 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1B1A6F5D for ; Fri, 14 Aug 2015 12:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham 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 66sevY_Aawma for ; Fri, 14 Aug 2015 12:08:24 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127CD1A7009 for ; Fri, 14 Aug 2015 12:07:45 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9CC2D6D78A; Fri, 14 Aug 2015 15:07:43 -0400 (EDT) Message-ID: <55CE3C86.2080909@iang.org> Date: Fri, 14 Aug 2015 20:07:50 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <9A043F3CF02CD34C8E74AC1594475C73F4AD7C72@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 19:08:26 -0000 On 13/08/2015 14:32 pm, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >> So let's not assume that these low-end processors are going away, please? >> >> Well the constraint on processing is easing up due to the move from RSA to ECC. > > Sure, it reduces computation time from tens of seconds down to ones of > seconds. ;) > >> And for the amount of data going though one of these processors, the choice of >> AES or DES doesn't make much of a difference. These things don't have to >> communicate very fast. >> >> The thing that gets really uncomfortable is dealing with the amount of memory >> available. Quite a few of the embedded chips have even less RAM than the >> Commodore PET I started with when 32KB was the large machine. > > Oh, yeah. Some of the environments I work in have like 2-4KB of RAM! https://www.youtube.com/watch?v=Xe1a1wHxTyo "And you try and tell the young people today..." :) >> Yes, these chips are not going away any time soon. The number of chips being >> made with 6502 based cores has increased every year since the 80s. But the >> problem with the chips isn't just that they are slow. > > I'm not seeing 6502, but I am seeing a lot of 8051. > > -derek > From nobody Sun Aug 16 22:23:22 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1073D1A9171 for ; Sun, 16 Aug 2015 22:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=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 eD7R4kMLhXBu for ; Sun, 16 Aug 2015 22:23:14 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143: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 0A0261A8958 for ; Sun, 16 Aug 2015 22:23:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2A379E2035; Mon, 17 Aug 2015 01:23:12 -0400 (EDT) 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 29917-02-3; Mon, 17 Aug 2015 01:23:10 -0400 (EDT) Received: from securerf.ihtfp.org (wsip-174-76-115-36.sb.sd.cox.net [174.76.115.36]) (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 4039AE2038; Mon, 17 Aug 2015 01:23:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1439788989; bh=aapJBWr2pS+t6AIu6oL5EumaVKyPcoLN8jK27QkDXGc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Yk1bQGLsD4qaZglLekh3+euyg1I3qVFncehUqdR5l1xw7rCZNP/YXvn7Vrtqsigi2 mbAuVeEYIws/H2sNkOX1E/2pp4I43aK5qA9nqIWuViRxgKOZRW5RR1TJ9x23vxYr3w J+8zyM74qR73hp9/h5mIScieubAlI+50o/wO18Ek= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7GFlvAx020300; Sun, 16 Aug 2015 11:47:57 -0400 From: Derek Atkins To: Bill Frantz References: Date: Sun, 16 Aug 2015 11:47:57 -0400 In-Reply-To: (Bill Frantz's message of "Fri, 14 Aug 2015 11:19:42 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Phillip Hallam-Baker , Derek Atkins , ianG , Peter Gutmann Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 05:23:15 -0000 Bill Frantz writes: > On 8/13/15 at 6:32 AM, derek@ihtfp.com (Derek Atkins) wrote: > >>>Yes, these chips are not going away any time soon. The number of chips being >>>made with 6502 based cores has increased every year since the 80s. But the >>>problem with the chips isn't just that they are slow. >> >>I'm not seeing 6502, but I am seeing a lot of 8051. > > I think in the IoT space, we will need to have signed software > updates. I don't think there is much of an issue taking several > seconds to verify an update signature, but these 8 bit processors seem > like the right level of hardware for these IoT devices. Yes, signed software is definitely one use case. However, often on these systems it's more than just authenticating a software update; sometimes it might actually want to check the signature on every bootup (to prevent an attack on the flash/firmware)! I'll note that there are alternate algorithms that run much faster than ECC (e.g. Algebraic Eraser can run in the tens of miliseconds instead of the ones of seconds of ECC)! However my real point is that we should not ignore these platforms, and more specifically we should remember that they might not have the power to run the same algorithms that work fine on our x86-64 servers. > Cheers - Bill -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 18 07:33:40 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CDA1A8868 for ; Tue, 18 Aug 2015 07:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 t9ZnzdR1acxZ for ; Tue, 18 Aug 2015 07:33:32 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5D79F1A8835 for ; Tue, 18 Aug 2015 07:33:32 -0700 (PDT) Received: from [174.236.35.178] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZRhwk-0002Xy-5c; Tue, 18 Aug 2015 10:33:02 -0400 Date: Tue, 18 Aug 2015 07:32:56 -0700 From: Bill Frantz To: Derek Atkins X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79028ad0478ae0b4e42677f7d913daecee350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.236.35.178 Archived-At: Cc: Peter Gutmann , IETF OpenPGP , Phillip Hallam-Baker , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 14:33:40 -0000 On 8/16/15 at 8:47 AM, derek@ihtfp.com (Derek Atkins) wrote: >Bill Frantz writes: > >>I think in the IoT space, we will need to have signed software >>updates. I don't think there is much of an issue taking several >>seconds to verify an update signature, but these 8 bit processors seem >>like the right level of hardware for these IoT devices. > >Yes, signed software is definitely one use case. However, often on >these systems it's more than just authenticating a software update; >sometimes it might actually want to check the signature on every bootup >(to prevent an attack on the flash/firmware)! I hope we don't have to worry about attacks via physical access,=20 so the only attacks available will be through the upgrade mechanism. We also need to worry about authentication and replay prevention=20 for the instructions delivered to these devices through the=20 internet. One can imagine an architecture with a controller with=20 the power of a Raspberry Pi giving orders to dumber devices=20 using authenticated symmetric crypto as a solution. That system=20 would prevent my favorite "neat hack" attack, turning your=20 neighbor's living room into your own light organ. >I'll note that there are alternate algorithms that run much faster than >ECC (e.g. Algebraic Eraser can run in the tens of miliseconds instead of >the ones of seconds of ECC)! However my real point is that we should >not ignore these platforms, and more specifically we should remember >that they might not have the power to run the same algorithms that work >fine on our x86-64 servers. I think we are in violent agreement here. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | If you want total security, go to prison.=20 There you're 408-356-8506 | fed, clothed, given medical care and so on.=20 The only www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower From nobody Tue Aug 18 07:53:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A55C1A009C for ; Tue, 18 Aug 2015 07:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 GzRHUwKcvRgE for ; Tue, 18 Aug 2015 07:53:16 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 CBD211A0074 for ; Tue, 18 Aug 2015 07:53:15 -0700 (PDT) Received: by qkbm65 with SMTP id m65so58899005qkb.2 for ; Tue, 18 Aug 2015 07:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KHzb5xUchhh5nMTPknUWYIopbJMcz9W6WQQTJqxLNVw=; b=09NUJI07LJ4QC9d/16zB8wwT5s3BlRLtZ97ybjQn8y1O3XH4V4yNlSSE5MBrl2ZGem j0GRCEow1Nm89j0TYJwLq3FgK58zkxV3l7GJ7/0VwA4i8sWlEW/nUluUmaOVJST1RBFz cfVgZGoVBgPRiEfk4aJvGhqcPT5SpNs9jaglCV4i5plU2xwjlH2DDF+h7MtBZsSfsiw2 MQ42WhOSHQDqL77UBw/eb/AykdpS7ZS1ov/+NPjkGlZqF9l2gs9zYXbrb6OQUqDkybIT tbXbTAZjCEkl1CMgYz8bub1nkJSceK9guh6IIINujrngDN92BfmM6clvtvLeI30O2ROz wNUA== MIME-Version: 1.0 X-Received: by 10.55.52.12 with SMTP id b12mr13465864qka.21.1439909594920; Tue, 18 Aug 2015 07:53:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.140.43.97 with HTTP; Tue, 18 Aug 2015 07:53:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Aug 2015 10:53:14 -0400 X-Google-Sender-Auth: n4MSCMYRmfXUkbJ2b8LSKYuRAuA Message-ID: From: Phillip Hallam-Baker To: Bill Frantz Content-Type: multipart/alternative; boundary=001a11478082ea05b4051d97135b Archived-At: Cc: Peter Gutmann , IETF OpenPGP , Derek Atkins , ianG Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 14:53:17 -0000 --001a11478082ea05b4051d97135b Content-Type: text/plain; charset=UTF-8 On Tue, Aug 18, 2015 at 10:32 AM, Bill Frantz wrote: > On 8/16/15 at 8:47 AM, derek@ihtfp.com (Derek Atkins) wrote: > > Bill Frantz writes: >> >> I think in the IoT space, we will need to have signed software >>> updates. I don't think there is much of an issue taking several >>> seconds to verify an update signature, but these 8 bit processors seem >>> like the right level of hardware for these IoT devices. >>> >> >> Yes, signed software is definitely one use case. However, often on >> these systems it's more than just authenticating a software update; >> sometimes it might actually want to check the signature on every bootup >> (to prevent an attack on the flash/firmware)! >> > > I hope we don't have to worry about attacks via physical access, so the > only attacks available will be through the upgrade mechanism. > > We also need to worry about authentication and replay prevention for the > instructions delivered to these devices through the internet. One can > imagine an architecture with a controller with the power of a Raspberry Pi > giving orders to dumber devices using authenticated symmetric crypto as a > solution. That system would prevent my favorite "neat hack" attack, turning > your neighbor's living room into your own light organ. Exactly the approach I want to see. Yes, it is absolutely true that 8 bit CPUs matter and I have been telling people that there are more of them produced every year than the last for over ten years now. BUT Anyone building a system who is trying to tell me that there is no room anywhere in that system for a $1 Raspberry Pi sized CPU and memory needs slapping with a cluestick. What I would really like right now is some low cost controller for two stepper motors that can sit off an IC2 serial port with all the commands being authenticated by a MAC. I don't need a lot of CPU power to be able to take commands off a slowish serial bus, authenticate them and set registers controlling a couple of steppers. Llama, my static hero sized dalek prop would like to be able to waggle his plunger and exterminator gun. The idea is that when someone enters the office without badging in, they get a surprise. --001a11478082ea05b4051d97135b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 18, 2015 at 10:32 AM, Bill Frantz <frantz@pwpconsult.c= om> wrote:
On 8/16/15 at 8:= 47 AM, derek@ihtfp.com= (Derek Atkins) wrote:

Bill Frantz <= frantz@pwpconsult.com> writes:

I think in the IoT space, we will need to have signed software
updates. I don't think there is much of an issue taking several
seconds to verify an update signature, but these 8 bit processors seem
like the right level of hardware for these IoT devices.

Yes, signed software is definitely one use case.=C2=A0 However, often on these systems it's more than just authenticating a software update;
sometimes it might actually want to check the signature on every bootup
(to prevent an attack on the flash/firmware)!

 I hope we don't have to worry about attacks via physical access, so the= only attacks available will be through the upgrade mechanism.

We also need to worry about authentication and replay prevention for the in= structions delivered to these devices through the internet. One can imagine= an architecture with a controller with the power of a Raspberry Pi giving = orders to dumber devices using authenticated symmetric crypto as a solution= . That system would prevent my favorite "neat hack" attack, turni= ng your neighbor's living room into your own light organ.
<= div>
Exactly the approach I want to see.

=
Yes, it is absolutely true that 8 bit CPUs matter and I have been tell= ing people that there are more of them produced every year than the last fo= r over ten years now.=C2=A0

BUT

Anyone building a system who is trying to tell me that there is no r= oom anywhere in that system for a $1 Raspberry Pi sized CPU and memory need= s slapping with a cluestick.=C2=A0


= What I would really like right now is some low cost controller for two step= per motors that can sit off an IC2 serial port with all the commands being = authenticated by a MAC. I don't need a lot of CPU power to be able to t= ake commands off a slowish serial bus, authenticate them and set registers = controlling a couple of steppers.=C2=A0

Llama, my = static hero sized dalek prop would like to be able to waggle his plunger an= d exterminator gun. The idea is that when someone enters the office without= badging in, they get a surprise.
--001a11478082ea05b4051d97135b-- From nobody Wed Aug 19 01:28:11 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66681AD0CF for ; Wed, 19 Aug 2015 01:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 8Qffj3yBrIa7 for ; Wed, 19 Aug 2015 01:28:06 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD891AD17F for ; Wed, 19 Aug 2015 01:28:00 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-04v.sys.comcast.net with comcast id 6YTt1r0035Geu2801YU0BD; Wed, 19 Aug 2015 08:28:00 +0000 Received: from [192.168.1.2] ([73.170.34.26]) by resomta-po-20v.sys.comcast.net with comcast id 6YTz1r0020ZpzqZ01YTziv; Wed, 19 Aug 2015 08:28:00 +0000 Message-ID: <55D43E0F.6080201@brainhub.org> Date: Wed, 19 Aug 2015 01:27:59 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> In-Reply-To: <87y4hmi19i.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1439972880; bh=B0bOYe1ZXiFSL51aGWgq72mFkkMRedROV5PS5m7UubE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VSSo1aB9MvCLm/WqjsbSDi2pNs2DCtk9p9T4MvmipsUOjIfgRbH61Av89ub0dmlN0 lLJViJ5pV9yMNpUZxIqNfbuWHsOgqkRBCKtkSWiXTSJmj6n3ASaTQmM1Z3CxtMMKwk ifyaprGlw4uy6ikDl6OqDdDWH/0Y0zRCVpnUriTjgoJiKZov5jjKVjaa23ESAtvCOe SfrIlH2zmOhbGA37qvXOLb0SffTf3hp/RmTSNgKqgo7Quy9zlFGn4tkDvjez2ToqS+ 8oYMzgNYhjrAqlwsiLwZYrim9zE8DWnqJbnuN3pSldsRddVug0lG/ABd4UNFaaHf0o ZaN7QgRNrKGWg== Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 08:28:09 -0000 On 08/08/2015 02:21 AM, Werner Koch wrote: > Hi! > > Now that an official SHA3 specs has been published I would like to see > algorithm ids assigned. Although it is some time until we can publish > rfc-4880bis, it would be useful to agree on the algorithm ids now. > This would be helpful for experimental implementations. Thus what about > this new table with the SHA2 drop in replacements: > > ID Algorithm Text Name > -- --------- --------- > 1 - MD5 [HAC] "MD5" > 2 - SHA-1 [FIPS180] "SHA1" > 3 - RIPE-MD/160 [HAC] "RIPEMD160" > 4 - Reserved > 5 - Reserved > 6 - Reserved > 7 - Reserved > 8 - SHA256 [FIPS180] "SHA256" > 9 - SHA384 [FIPS180] "SHA384" > 10 - SHA512 [FIPS180] "SHA512" > 11 - SHA224 [FIPS180] "SHA224" > 12 - SHA3-224 [FIPS202] "SHA3-224" > 13 - SHA3-256 [FIPS202] "SHA3-256" > 14 - SHA3-384 [FIPS202] "SHA3-384" > 15 - SHA3-512 [FIPS202] "SHA3-512" > 100 to 110 - Private/Experimental algorithm > > Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224 > and thus it ended up out of order. > > I am not sure about the text name. Is a dash okay (cf. armor header)? > > The OIDS are: > > The hexadecimal representations for the > currently defined hash algorithms are as follows: > > [...] > > - SHA3-224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07 > - SHA3-256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08 > - SHA3-384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x09 > - SHA3-512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a > > The ASN.1 Object Identifiers (OIDs) are as follows: > > [...] > > - SHA3-224: 2.16.840.1.101.3.4.2.7 > - SHA3-256: 2.16.840.1.101.3.4.2.8 > - SHA3-384: 2.16.840.1.101.3.4.2.9 > - SHA3-512: 2.16.840.1.101.3.4.2.10 > > The full hash prefixes for these are as follows: > > [...] > > SHA3-224: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > SHA3-256: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > SHA3-384: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > > SHA3-512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, > 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05, > 0x00, 0x04, 0x40 > Dear OpenPGP list members. NIST has finally produced the SHA-3 spec, FIPS 202 http://dx.doi.org/10.6028/NIST.FIPS.202. It is difficult to believe that the last discussion on SHA3 ID that I recall was in 2012 in https://lists.gnupg.org/pipermail/gnupg-devel/2012-December/027173.html . I have updated and posted the ID with details that were discussed so far in the thread, here: > > A new version of I-D, draft-jivsov-openpgp-sha3-00.txt > has been successfully submitted by Andrey Jivsov and posted to the > IETF repository. > > Name: draft-jivsov-openpgp-sha3 > Revision: 00 > Title: The use of Secure Hash Algorithm 3 in OpenPGP > Document date: 2015-08-19 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-jivsov-openpgp-sha3-00.txt > Status: https://datatracker.ietf.org/doc/draft-jivsov-openpgp-sha3/ > Htmlized: https://tools.ietf.org/html/draft-jivsov-openpgp-sha3-00 > > > Abstract: > This document presents the necessary information to implement the > SHA-3 hash algorithm with the OpenPGP format. Your comments are very welcome. The idea of the spec is to keep technical details written down, such as IDs, ASN.1 DER prefixes, and the exact set/subset of SHA3 algorithms. I also think that a few words on interoperability concerns will be helpful. Second, and this took the most time, I wrote a single-file C code SHA3 implementation that should assist with the implementation of SHA3 in OpenPGP applications, testing, troubleshooting, and interoperability. One feature of this sample is that it follows Init/Update/Finalize (IUF) API, which is how OpenPGP uses the message digest. The project is called SHA3IUF. The code is here: https://github.com/brainhub/SHA3IUF To run the sample code: $ wget https://raw.githubusercontent.com/brainhub/SHA3IUF/master/sha3.c $ gcc -Wall sha3.c -o _ && ./_ SHA3-256, SHA3-384, SHA3-512 tests passed OK I hope that a spec and the SHA3IUF sample code will help avoid mistakes, such as the one in the above quoted message. All DER prefixes except for the SHA3-512 are incorrect. Please use the DER prefixes from the spec. SHA3 is not the same as Keccak, and the two produce different hash values. SHA3IUF helps with other issues, such as how to define the IUF state, and how difficult is it to add each SHA3-X algorithm. Presently the spec excludes SHA3-224, as seems to be a consensus on this list. Please note that presently DSA or ECDSA truncate hashes. A digital signature with a DSA key with FIPS 186-3 L=2048 N=224 and a SHA3-256 hash algorithm has security properties similar to the case when SHA3-224 hash was used instead. In other words, an application already has a tool to use a 224-bit hash via an appropriate DSA/ECDSA key. RSA signatures have plenty of "free" space for the hash, therefore, it's not clear why SHA3-224 would be needed. Thank you. From nobody Wed Aug 19 02:45:40 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A550B1B29B5 for ; Wed, 19 Aug 2015 02:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kOccn6KQBSr0 for ; Wed, 19 Aug 2015 02:45:34 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EEB1B29B6 for ; Wed, 19 Aug 2015 02:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439977534; x=1471513534; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0QX0Qnizx8SdhhmvbjjtwpvDHbfZgEr+Oxb/WQJtfQA=; b=qMa9Z7rswGZm/Px6+mwFVMQLWHnkGEbxxvHC4VNWf60mNB0eB37ezkYS NxvDhgHXoC/NIcDe8RQ94+AjTbOs6TZUWs/c0t0JZJEZReegsXFydmk+M FwXnOOzeMI8My5Uhtp6v/97KrXUwlqEy2W14XFLVT6JbZrJLJvxwG/bhb ++0shSY/G2w9hoE84gtw2P98G86pkzAVz+4+AQkRZ57SNa6P0hS63eH9W JJufwKA5eKTpypgMP/naHuuuhmFzILEvxbr3iPQ59pmEZTrmY9AC6Sogf LyuvHqCK4dozwgJam3XjVKIcPoatKCGOfB85MA6XGDHOFh6rXxHbefDwu Q==; X-IronPort-AV: E=Sophos;i="5.15,709,1432555200"; d="scan'208";a="36205847" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Aug 2015 21:45:32 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 19 Aug 2015 21:45:32 +1200 From: Peter Gutmann To: Andrey Jivsov , "openpgp@ietf.org" Thread-Topic: [openpgp] SHA3 algorithm ids. Thread-Index: AQHQ0bwwjUQponxgXEGSKRaVthfi2J4SRUaAgADeZnI= Date: Wed, 19 Aug 2015 09:45:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4ADF89F@uxcn10-5.UoA.auckland.ac.nz> References: <87y4hmi19i.fsf@vigenere.g10code.de>, <55D43E0F.6080201@brainhub.org> In-Reply-To: <55D43E0F.6080201@brainhub.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 09:45:39 -0000 Andrey Jivsov quoted Werner Koch:=0A= =0A= > Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224= =0A= > and thus it ended up out of order.=0A= =0A= And that's pretty much what the -224 hashes are, forgettable (and -384 only= =0A= slightly less so). There's an obvious need for -256, and then you need -51= 2=0A= for people who need hashes that go to 11, but what's the point of -224 and= =0A= -384 in OpenPGP? Are users really going to say "well, everyone else is usi= ng=0A= -256 and I like to be different, but -512 is too big, and -384 just doesn't= go=0A= with the tie I'm wearing, so I'm really glad there's -224 as well"? It's j= ust=0A= more bloat in the spec (and implementations) that'll never be used by anyon= e.=0A= It was forgotten in 4880, it should be forgotten in x880 as well (along wit= h=0A= the equally useless -384).=0A= =0A= Peter.= From nobody Wed Aug 19 06:48:01 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5381A1B16 for ; Wed, 19 Aug 2015 06:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6HgplzRd4E8b for ; Wed, 19 Aug 2015 06:47:59 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641BF1A044F for ; Wed, 19 Aug 2015 06:47:59 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id BB0136D7E8; Wed, 19 Aug 2015 09:47:57 -0400 (EDT) Message-ID: <55D4890C.7000101@iang.org> Date: Wed, 19 Aug 2015 14:47:56 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <55D43E0F.6080201@brainhub.org> In-Reply-To: <55D43E0F.6080201@brainhub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 13:48:00 -0000 On 19/08/2015 09:27 am, Andrey Jivsov wrote: > Please note that presently DSA or ECDSA truncate hashes. A digital > signature with a DSA key with FIPS 186-3 L=2048 N=224 and a SHA3-256 > hash algorithm has security properties similar to the case when SHA3-224 > hash was used instead. In other words, an application already has a tool > to use a 224-bit hash via an appropriate DSA/ECDSA key. > > RSA signatures have plenty of "free" space for the hash, therefore, it's > not clear why SHA3-224 would be needed. For reasons like the above and the rest of the conversation (and Peter's comment), I think we should be examining SHAKE more closely. The world of hashes has changed fundamentally because of Sponge. The old assumptions embedded in the above are literally that - old, tired, historical. If we want to make OpenPGP for the future, we want to have a stab at aiming for that future. iang From nobody Wed Aug 19 07:19:40 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1D01A898B for ; Wed, 19 Aug 2015 07:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 zDhbhEkHbcqc for ; Wed, 19 Aug 2015 07:19:37 -0700 (PDT) Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2001:4f8:3:36:211:85ff:fe63:a549]) by ietfa.amsl.com (Postfix) with ESMTP id 7912C1A21BA for ; Wed, 19 Aug 2015 07:19:37 -0700 (PDT) Received: from [10.10.142.30] (wsip-70-167-255-237.dc.dc.cox.net [70.167.255.237]) (Authenticated sender: rjh-sixdemonbag) by shards.monkeyblade.net (Postfix) with ESMTPSA id D7F6E589463 for ; Wed, 19 Aug 2015 07:19:36 -0700 (PDT) To: openpgp@ietf.org References: <87y4hmi19i.fsf@vigenere.g10code.de> <55D43E0F.6080201@brainhub.org> <9A043F3CF02CD34C8E74AC1594475C73F4ADF89F@uxcn10-5.UoA.auckland.ac.nz> From: "Robert J. Hansen" Message-ID: <55D49077.5020205@sixdemonbag.org> Date: Wed, 19 Aug 2015 10:19:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4ADF89F@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 19 Aug 2015 07:19:37 -0700 (PDT) Archived-At: Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 14:19:39 -0000 > And that's pretty much what the -224 hashes are, forgettable (and > -384 only slightly less so). There's an obvious need for -256, and > then you need -512 for people who need hashes that go to 11, but > what's the point of -224 and -384 in OpenPGP? IIRC, early drafts of DSA2 required a 224-bit hash for DSA-2048 and didn't allow for the possibility of a truncated 256-bit hash. Later revisions corrected this oversight. That's where it got into the spec: because at the time it got into the spec, SHA-224 was required for conformance. From nobody Thu Aug 20 06:10:41 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2F21ACE1F for ; Thu, 20 Aug 2015 06:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 reY1lz3i_wSB for ; Thu, 20 Aug 2015 06:10:38 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DEB1ACE20 for ; Thu, 20 Aug 2015 06:10:37 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZSPc4-0007lo-9h for ; Thu, 20 Aug 2015 15:10:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZSPZl-0005sR-Q9; Thu, 20 Aug 2015 15:08:13 +0200 From: Werner Koch To: Peter Gutmann References: <87y4hmi19i.fsf@vigenere.g10code.de> <55D43E0F.6080201@brainhub.org> <9A043F3CF02CD34C8E74AC1594475C73F4ADF89F@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Andrey Jivsov , "openpgp\@ietf.org" Date: Thu, 20 Aug 2015 15:08:13 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4ADF89F@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 19 Aug 2015 09:45:31 +0000") Message-ID: <87d1yixg3m.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Andrey Jivsov , "openpgp@ietf.org" Subject: Re: [openpgp] SHA3 algorithm ids. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:10:39 -0000 On Wed, 19 Aug 2015 11:45, pgut001@cs.auckland.ac.nz said: > more bloat in the spec (and implementations) that'll never be used by anyone. > It was forgotten in 4880, it should be forgotten in x880 as well (along with > the equally useless -384). Okay, you convinced me. I retract my request to pre-allocate algo id for SHA-3. Let's add them if it turns out that they are required. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.