From nobody Wed Apr 6 11:16:08 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FFB12D1F0 for ; Wed, 6 Apr 2016 11:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kh--F6MEhSA for ; Wed, 6 Apr 2016 11:16:05 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 0759E12D0E1 for ; Wed, 6 Apr 2016 11:16:05 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f105so19261069qge.2 for ; Wed, 06 Apr 2016 11:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:message-id:references:to; bh=wJovbGKs5fJe0/nL+cb4A72TTJxeWgiHZ2hrnhcgfrE=; b=AEFylmC9HWbmHc2EQHuITnxctTx3qj/ZJPQTZT6JklG6rWZaA7msZRxVijHX6UjY6r cAEyE5RhNCegBGN2+Tw+CgEiIFVsz7V1bWdEKLaABMhDM7A6LCto4oo1I3mARQUuk1q/ fKMpAQDwji6P7IiRmiZM7fwYiJKWRupP5EaM/9ZfiealIM53BW554qx0QCj6DXHAvf6p QJorpdRtTFrqnLfeY4I/DEgMw6jR9K8e7sKO9re4AkmaBvwkoXITG3aBgAoYLbdeva5C lGIfGW+VXzzMOlIwyp81LM9uUZceznERMq9rnyduJSFQ/wyejptwJhxIxXnqDW8oxPVd M8JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :message-id:references:to; bh=wJovbGKs5fJe0/nL+cb4A72TTJxeWgiHZ2hrnhcgfrE=; b=mnJ6iUT1CZM3jHQbciWQjhPUP67/X8b+runBGp01SrbzB44/qIVBUUjRVkyCylXR2w FTvZLt61nD3qH5jkMkgwaAf02crlzTWYa9yifZSvB3p4p8idoSWb5yyAfcYeY0OHTHyw eBqHHnGV/KrBNESd9dgHXVjXaCsuWNYyS/AfqkPBSBo8erpU2d2nkDvLEbu2CzOGQa/o wDr6KmKmLsh31Hg4rIpxRKvkYBTenD17QJ6SB4cP64YkibAMvCgcSMnBlgBlXTgsHGfe uBonEiQi6OjPEuE+Lo5AfbkQ9R0LXg1NYr3eqdJmmSlo+EYcwyuCULUcSNd4YCdmWedh Jt/Q== X-Gm-Message-State: AD7BkJJ+f5iMG0bySQVzINdi/pqjYhQ6Bgnz4RX507O2gzRQzZoYwJv66gwIkFcN133K7A== X-Received: by 10.140.28.52 with SMTP id 49mr37430599qgy.66.1459966564063; Wed, 06 Apr 2016 11:16:04 -0700 (PDT) Received: from [192.168.1.9] ([186.60.153.174]) by smtp.gmail.com with ESMTPSA id f13sm1028747qke.43.2016.04.06.11.16.01 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 11:16:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D773E599-4E56-4858-958A-E4D5A7408896"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Bryan Ford In-Reply-To: <20151110021943.GH3896@vauxhall.crustytoothpaste.net> Date: Wed, 6 Apr 2016 15:15:59 -0300 Message-Id: <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> To: openpgp@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:16:07 -0000 --Apple-Mail=_D773E599-4E56-4858-958A-E4D5A7408896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To followup on today=E2=80=99s in-meeting discussion of evolving OpenPGP = fingerprints beyond SHA-1, I want to propose that there are at least two = orthogonal issues to decide (and I=E2=80=99m probably not the first to = suggest this): 1. What fingerprint scheme(s) should OpenPGP move to going forward? 2. What exactly should the OpenPGP =E2=80=9Capplication=E2=80=9D = fingerprint with that scheme? To clarify, I propose to define a =E2=80=9Cfingerprint scheme=E2=80=9D = as an algorithm that takes a raw octet string and produces an ASCII = string of some kind for users to cut-and-paste, compare, read off over = the phone, etc. By this definition, just like a cryptographic =E2=80=9Cha= sh scheme=E2=80=9D or =E2=80=9Csignature scheme=E2=80=9D, the = =E2=80=9Cfingerprint scheme=E2=80=9D itself doesn=E2=80=99t need to know = or care what octet string gets fed into it. As such there=E2=80=99s no reason such a =E2=80=9Cfingerprint scheme=E2=80= =9D itself needs to be in any way specific to OpenPGP, and I would = support the proposals that Phillip and others have made that it would be = ideal to standardize future fingerprint scheme(s) independently of = particular protocols such as OpenPGP, and just have OpenPGP use that = scheme. CFRG might be the obvious place to do this. Of course, I = understand the logistical downsides of having an OpenPGP work-item = depend on work elsewhere (e.g., CFRG) that isn=E2=80=99t even started = yet=E2=80=A6 But this approach might still be worth considering from a = =E2=80=9Cget it right=E2=80=9D perspective if there isn=E2=80=99t = currently some kind of severe time pressure on the OpenPGP side. The other, very OpenPGP-specific, question is of course what exact = octet-string should get fed into whatever fingerprint scheme is chosen. = DKG brought up the question of whether that octet-string should still = include the Unix timestamp like it currently does. I think that = question leads to a bigger set of issues that I=E2=80=99ll try to tease = apart in a subsequent E-mail. But first I just wanted to propose this explicit separation of the two = questions, =E2=80=9Cwhich fingerprint scheme?=E2=80=9D (i.e., which = function from octet-strings to ASCII-strings), and =E2=80=9Cwhat to = fingerprint?=E2=80=9D (how does OpenPGP get from a key to the = octet-string to feed the fingerprint scheme?). Thanks Bryan --Apple-Mail=_D773E599-4E56-4858-958A-E4D5A7408896 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBVJgAAoJEGt1rlrP7+d/kZ8QAKb+f5R2+xuzwIzplzVR/1nt 1nzLsn7k+KB6hX2FJNiO0R6rMURzqIxG9WRTVkIJboTLw7xur3jmaGPHueIkJ2ie UwjT7NrxZrpnYeuicXOO1625HtUjbI6PBlKVY/CjjQRyFMs/g02Uc+KzTRFQXDvC 6/Y5fhsEMAVMtlWUn7URnEcot2aar8zsGd5DTGkRNWG+xRUA58IEpxMZzO/X1/z6 yy0Ke0A+yDoSkiTQBJfp2QQBauJG+/cjJbFQRsiAof8cy9iSkvjmndZrzpSCYSg2 X5IXxIyLP11IgLkXhoxTj0d9EY4M4wWcdiOBN9Y6/O817KiB1g00AECpsAXqkzgD tMcQK007b9eZQzSrKup/agJTOAT1nFtNStvEln4a2EPy9xPRviZYsMTtI+Pyvq2C OsQV6JHs/WegPBoPlAY8Lh+DdEm0Z6k1iQ0qIW/S++TQEr9xeZx2rrj7VgsfaGai xIk3vwrUboaFuiua/apnbRU+t2XvUr08VqFlq2pX7MPULDshOREX19uQ3LfZyMBT o0cvTVtTPjEiXBKsluT9UYve/9foU18oLkY3lHj8JnabHZpgYUYeIhPISivUqefx y9kU13Q9TaTG5JPfs/nGy6aDIzXWfBZrIXU6hm1UasmoogzkhmIP9y6QZseyBr7K Au1UYhSkMYcATmMDb77n =gyjX -----END PGP SIGNATURE----- --Apple-Mail=_D773E599-4E56-4858-958A-E4D5A7408896-- From nobody Wed Apr 6 12:20:18 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9162912D614 for ; Wed, 6 Apr 2016 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e6UqG9Jw9bg for ; Wed, 6 Apr 2016 12:20:14 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5665312D5C1 for ; Wed, 6 Apr 2016 12:20:14 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id k135so17969904qke.0 for ; Wed, 06 Apr 2016 12:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=ZWEInWNcjTGsfvuw81YW0q6Abg/xZskzsC5CR08+zA0=; b=G1iyomAWUvxqG4woaNPkOeVqypoTiM+rei9U5b+Di3slSPRg8KVQTcrfbQjXhwm+Nx Uy+bsuZHsOWFTW3Q3SRC0fnwia5EetPPm9OoDkMiYMtp0Zwbi6LdIKVJDYEL8Co/GiJe hcbp6IHhbpZdgSlkK65i1Qr5yvu3REXnBZ1lOBPECoYS7L2PWCNlV3mpDgfsZ+rZUY8g Ul4StXfDshTYp/07KwpbTEvNNB05kY/+cu69Y1Us0/1kyoKU/wM7POvE6rqd7cQeuHG0 YH3K1Nxu0AmkpsB+DW8diAJ4dmZpXRBP6iQhJebp6NMRzo1ukbCZKHenXMMdhsQA6R4w FgkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=ZWEInWNcjTGsfvuw81YW0q6Abg/xZskzsC5CR08+zA0=; b=IUfB2XY7UPkG47dlubnQ01Oz1+NiVpLx45Q/d4ihPbQrj9txuygKTdWFULAwsRKtJi UGBBh7fLsTnzuGl14H3Ztl3x/8d1tBaDbHmtoAk8jipFaA7I+/eVQPx8zXKV+vyYckEE mpPpmOx+o60H44Fl/F0TCTp41VBDvdNw8DLletSGbTzlSj3DR1cCWbCKN0yXqHD42MZa jVHMLN3E77lgTQKQAmwfObdrsht2yPG/f4hMrrA8cNG/E4MFwV7zzcqxz4W94sEiHJ0v hrR/30mpdBvxEWYFczEwCtecrIKZgvrQEGn1xO63uTSp0GfBC4FTd2H9+Lz7W3dZ+vw1 +CHA== X-Gm-Message-State: AD7BkJIXNQJdVr8z9K77RG8X022fha4/jafxAXA/PTBgh9Nv7fsuk9Gd/lx2JKfZTij+ZA== X-Received: by 10.55.214.1 with SMTP id t1mr51020222qki.4.1459970413356; Wed, 06 Apr 2016 12:20:13 -0700 (PDT) Received: from [192.168.1.9] ([186.60.153.174]) by smtp.gmail.com with ESMTPSA id 78sm1902581qgt.1.2016.04.06.12.20.10 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 12:20:11 -0700 (PDT) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_05F800FC-41EB-43FD-9CCB-41E8DF4BE927"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Wed, 6 Apr 2016 16:20:08 -0300 To: openpgp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:20:17 -0000 --Apple-Mail=_05F800FC-41EB-43FD-9CCB-41E8DF4BE927 Content-Type: multipart/alternative; boundary="Apple-Mail=_13C916B5-5CF4-4A1C-80CA-8FD6CC419244" --Apple-Mail=_13C916B5-5CF4-4A1C-80CA-8FD6CC419244 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Getting back to DKG=E2=80=99s question of whether the Unix = creation-timestamp should be included in the octet-stream passed to a = (future) OpenPGP fingerprint scheme=E2=80=A6 I want to generalize the = question into a choice between three options: 1. The fingerprint covers *only* the public-key material itself, in a = verifiably and enforceably canonical form. 2. The fingerprint covers the public-key material and some other = fixed-format stuff like version info and Unix timestamp, as in rfc4880. 3. The fingerprint covers the public-key material and some extensible = variable-length information, e.g., parameters the key-holder specifies = in its self-signed cert at key creation time. As you can guess I think choice 2 really makes no sense, as it=E2=80=99s = kind of an uncomfortable midpoint between two design approaches that has = important downsides of both but doesn=E2=80=99t really achieve the = benefits of either. So I=E2=80=99ll just focus now on #1 versus #3. The advantages I see to approach #1 (fingerprint covers public-key ONLY) = are: (a) simplicity in specification and implementation; and (b) there = may be security benefits in any public-key having one and only one = fingerprint - IF canonical encoding is 100% enforced in current OpenPGP = implementations, which may or may not be the case. The advantages I see to approach #3 (fingerprint covers public-key and = some extensible information) are that the key=E2=80=99s creator can bind = to the key, at creation time, additional information that other parties = might subsequently use in checking the validity or revocation status of = a key, when importing or checking its fingerprint. The current = fixed-format bundling of Unix creation-time into the fingerprinted = octet-string is just a ridiculously restrictive special-case of this = otherwise potentially not-bad idea. The question, as DKG brought up in = the session, is what the range of benefits are that we might get from = this flexibility, and whether they justify the added complexity, and any = security risks that may arise from non-canonical fingerprints. The general (potential) risk here - although I=E2=80=99m not sure how = =E2=80=9Creal=E2=80=9D it is - is that either the key-holder, or someone = who manages to steal the key, can tweak the creation-timestamp and/or = any other non-canonical bits that the fingerprint depends on, to create = a new =E2=80=9Cpublic key=E2=80=9D with a different fingerprint but the = same key material as the old one. One obvious =E2=80=9Cbad thing=E2=80=9D= that might happen is if a key-thief could use this to trick other = people into not realizing a revoked key was revoked, because the = key-thief is reusing the key under a different fingerprint. But so far = I haven=E2=80=99t been able to put together realistic-sounding attack = scenarios. I think this is in part because for anyone to trust that key = in the first place, they presumably need to have verified it somehow, = typically by doing something with the fingerprint, and hence an attacker = who reuses a stolen/broken key with a new fingerprint doesn=E2=80=99t = get any benefit because the new fingerprint isn=E2=80=99t = verified/trusted by anyone. The question is where these assumptions = might fail, e.g., some application attaches trust to keys directly = without verifying their fingerprints, and becomes vulnerable to this = class of attack. On the upside of allowing the fingerprint to depend on non-canonical = (e.g., creator-provided) information, I understand Phil is going to post = a document listing some of the uses for this type of functionality, and = I look forward to seeing that. But just to list a few potential uses I = can think of: - This information could include a creation-timestamp as a Unix time, as = it is now. - This information could include a more verifiable analog to a = creation-timestamp, e.g., a signed timestamp record from a digital = timestamp or notary service that actually vouches for the timestamp and = publishes the timestamp in a public log. OpenPGP implementations that = receive a public key and validate it against this fingerprint could (but = wouldn=E2=80=99t necessarily always have to) verify the signed timestamp = record, and could even (again optionally) check its presence in the = public log. This might be the way to get closer to the actual security = benefit that presumably motivated the inclusion of the creation = timestamp in the original OpenPGP spec: e.g., it would provide some = actual publicly-verifiable evidence of when the key was first created, = and make it difficult for an attacker to =E2=80=9Cre-create=E2=80=9D a = broken key later without that attack being detectable. - The information covered by the fingerprint could include =E2=80=9Chardne= ss parameters=E2=80=9D that feed into the fingerprint scheme itself, = enabling the key creator to obtain a configurable level of protection = for the key from fingerprint-mining attacks where an attacker tries to = search for other keys with fingerprints that match in the first several = digits. This was discussed at the last IETF meeting, and subsequently = on this mailing list thread, so I won=E2=80=99t repeat it at length = here: = https://www.ietf.org/mail-archive/web/openpgp/current/msg08478.html = - The information covered by the fingerprint could include hash-pointers = to blockchain transactions in order to incorporate blockchain-randomness = into the fingerprint (see https://eprint.iacr.org/2015/1015.pdf = ), thereby making it extremely = expensive, if not effectively impossible, for an attacker to produce = another key with the same or even a similar-looking fingerprint without = the attack likely being detected. Not every OpenPGP implementation = would necessarily be expected to know how to actually verify this = blockchain-randomness; implementations that don=E2=80=99t support it = would just see it as an opaque blob of information that the fingerprint = covers but that they otherwise don=E2=80=99t interpret. - The information covered by the fingerprint could specify additional = =E2=80=9Ccanary=E2=80=9D or revocation conditions by which parties using = the key might more quickly/securely detect if and when the key might = have been compromised. For example, this information could contain a = =E2=80=9Cfinancially incentivized auto-revocation=E2=80=9D: e.g., a = hash-pointer to an unspent Bitcoin transaction output which, if and when = it is ever spent, is to be interpreted by everyone as an implicit = revocation of the associated PGP key. The key-holder funds a =E2=80=9Ckey= compromise bounty=E2=80=9D by depositing some amount of Bitcoin in an = account whose private key can be derived from the PGP private key. Then = if a hacker ever steals the private PG key, they get access to the = bounty - but in transferring/spending it they effectively cause the PGP = key to be publicly revoked, making that immediately detectable to any = OpenPGP implementations that happen to support this auto-revocation = mechanism. Of course the hacker might choose to leave the bounty = unspent in order to avoid compromise detection, but the higher the = bounty, the fewer attackers will want to make that choice. I=E2=80=99m not going to make the case that any of these potential = benefits of non-canonical fingerprints are absolutely essential, but = rather just explore the possibly interesting space of potential benefits = from being able to use fingerprints to verify more than just a raw = public key alone. Further thoughts welcome. Cheers Bryan --Apple-Mail=_13C916B5-5CF4-4A1C-80CA-8FD6CC419244 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Getting back to = DKG=E2=80=99s question of whether the Unix creation-timestamp should be = included in the octet-stream passed to a (future) OpenPGP fingerprint = scheme=E2=80=A6  I want to generalize the question into a choice = between three options:

1. The fingerprint covers *only* the public-key material = itself, in a verifiably and enforceably canonical form.

2. The fingerprint = covers the public-key material and some other fixed-format stuff like = version info and Unix timestamp, as in rfc4880.

3. The fingerprint = covers the public-key material and some extensible variable-length = information, e.g., parameters the key-holder specifies in its = self-signed cert at key creation time.

As you can guess I think choice 2 = really makes no sense, as it=E2=80=99s kind of an uncomfortable midpoint = between two design approaches that has important downsides of both but = doesn=E2=80=99t really achieve the benefits of either.  So I=E2=80=99= ll just focus now on #1 versus #3.

The advantages I see to approach #1 = (fingerprint covers public-key ONLY) are: (a) simplicity in = specification and implementation; and (b) there may be security benefits = in any public-key having one and only one fingerprint - IF canonical = encoding is 100% enforced in current OpenPGP implementations, which may = or may not be the case.

The advantages I see to approach #3 (fingerprint covers = public-key and some extensible information) are that the key=E2=80=99s = creator can bind to the key, at creation time, additional information = that other parties might subsequently use in checking the validity or = revocation status of a key, when importing or checking its fingerprint. =  The current fixed-format bundling of Unix creation-time into the = fingerprinted octet-string is just a ridiculously restrictive = special-case of this otherwise potentially not-bad idea.  The = question, as DKG brought up in the session, is what the range of = benefits are that we might get from this flexibility, and whether they = justify the added complexity, and any security risks that may arise from = non-canonical fingerprints.

The general (potential) risk here - although = I=E2=80=99m not sure how =E2=80=9Creal=E2=80=9D it is - is that either = the key-holder, or someone who manages to steal the key, can tweak the = creation-timestamp and/or any other non-canonical bits that the = fingerprint depends on, to create a new =E2=80=9Cpublic key=E2=80=9D = with a different fingerprint but the same key material as the old one. =  One obvious =E2=80=9Cbad thing=E2=80=9D that might happen is if a = key-thief could use this to trick other people into not realizing a = revoked key was revoked, because the key-thief is reusing the key under = a different fingerprint.  But so far I haven=E2=80=99t been able to = put together realistic-sounding attack scenarios.  I think this is = in part because for anyone to trust that key in the first place, they = presumably need to have verified it somehow, typically by doing = something with the fingerprint, and hence an attacker who reuses a = stolen/broken key with a new fingerprint doesn=E2=80=99t get any benefit = because the new fingerprint isn=E2=80=99t verified/trusted by anyone. =  The question is where these assumptions might fail, e.g., some = application attaches trust to keys directly without verifying their = fingerprints, and becomes vulnerable to this class of attack.

On the upside of = allowing the fingerprint to depend on non-canonical (e.g., = creator-provided) information, I understand Phil is going to post a = document listing some of the uses for this type of functionality, and I = look forward to seeing that.  But just to list a few potential uses = I can think of:

- This information could include a creation-timestamp as a = Unix time, as it is now.

- This information could include a more verifiable analog to = a creation-timestamp, e.g., a signed timestamp record from a digital = timestamp or notary service that actually vouches for the timestamp and = publishes the timestamp in a public log.  OpenPGP implementations = that receive a public key and validate it against this fingerprint could = (but wouldn=E2=80=99t necessarily always have to) verify the signed = timestamp record, and could even (again optionally) check its presence = in the public log.  This might be the way to get closer to the = actual security benefit that presumably motivated the inclusion of the = creation timestamp in the original OpenPGP spec: e.g., it would provide = some actual publicly-verifiable evidence of when the key was first = created, and make it difficult for an attacker to =E2=80=9Cre-create=E2=80= =9D a broken key later without that attack being detectable.

- The information = covered by the fingerprint could include =E2=80=9Chardness parameters=E2=80= =9D that feed into the fingerprint scheme itself, enabling the key = creator to obtain a configurable level of protection for the key from = fingerprint-mining attacks where an attacker tries to search for other = keys with fingerprints that match in the first several digits. =  This was discussed at the last IETF meeting, and subsequently on = this mailing list thread, so I won=E2=80=99t repeat it at length = here: https://www.ietf.org/mail-archive/web/openpgp/current/msg08478.= html

- The = information covered by the fingerprint could include hash-pointers to = blockchain transactions in order to incorporate blockchain-randomness = into the fingerprint (see https://eprint.iacr.org/2015/1015.pdf), thereby making it = extremely expensive, if not effectively impossible, for  an = attacker to produce another key with the same or even a similar-looking = fingerprint without the attack likely being detected.  Not every = OpenPGP implementation would necessarily be expected to know how to = actually verify this blockchain-randomness; implementations that don=E2=80= =99t support it would just see it as an opaque blob of information that = the fingerprint covers but that they otherwise don=E2=80=99t = interpret.

- = The information covered by the fingerprint could specify additional = =E2=80=9Ccanary=E2=80=9D or revocation conditions by which parties using = the key might more quickly/securely detect if and when the key might = have been compromised.  For example, this information could contain = a =E2=80=9Cfinancially incentivized auto-revocation=E2=80=9D: e.g., a = hash-pointer to an unspent Bitcoin transaction output which, if and when = it is ever spent, is to be interpreted by everyone as an implicit = revocation of the associated PGP key.  The key-holder funds a = =E2=80=9Ckey compromise bounty=E2=80=9D by depositing some amount of = Bitcoin in an account whose private key can be derived from the PGP = private key.  Then if a hacker ever steals the private PG key, they = get access to the bounty - but in transferring/spending it they = effectively cause the PGP key to be publicly revoked, making that = immediately detectable to any OpenPGP implementations that happen to = support this auto-revocation mechanism.  Of course the hacker might = choose to leave the bounty unspent in order to avoid compromise = detection, but the higher the bounty, the fewer attackers will want to = make that choice.

I=E2=80=99m not going to make the case that any of these = potential benefits of non-canonical fingerprints are absolutely = essential, but rather just explore the possibly interesting space of = potential benefits from being able to use fingerprints to verify more = than just a raw public key alone.  Further thoughts = welcome.

Cheers
Bryan


= --Apple-Mail=_13C916B5-5CF4-4A1C-80CA-8FD6CC419244-- --Apple-Mail=_05F800FC-41EB-43FD-9CCB-41E8DF4BE927 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDYxOTIwMDhaMCMGCSqGSIb3DQEJBDEWBBQBnevp8Bd6RB7LFUZZRAytM0yyHTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAf65l30hzHY0vBmUPMCHRs9wp56CaDOJRcXt19XbXter1Cnaai8Bve2dCkwcqU/1E kFJPxjslOD+RC5gUfMvug7/8TDyXF/6http6J3d0bUWz8oAuULvAFGH0xcaH3k6wOwUAq5ene6Rw gqYVoKfdkH7JVCNRYDasveo7FyLNweoVgpJAPpVj4FI+UJyW5aGF2tWk/OkrfaJVdtiFbopqZ0UG 3NG/r7Bv1y1sX6avKg9s/to6IYqi1z4NEwYNovlo78Rk0GfeJODRWVq3r1na+pCAH48EkV4NJZcz CC5MZBFjNCBZHh5DY1q0h1MGR/C006uUhZ+zwhYlt+J9iwUfkwAAAAAAAA== --Apple-Mail=_05F800FC-41EB-43FD-9CCB-41E8DF4BE927-- From nobody Wed Apr 6 13:00:14 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8094C12D622 for ; Wed, 6 Apr 2016 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9bIGHt7hzX2 for ; Wed, 6 Apr 2016 13:00:11 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 C8E0212D608 for ; Wed, 6 Apr 2016 13:00:10 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id j35so45593164qge.0 for ; Wed, 06 Apr 2016 13:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:to:mime-version; bh=dFgxTimLFzoMlhqSiAL9/HhO3S0b/O2ri7x/cORyNI4=; b=avK7iiI9kV1jeG64hx0R4QK0XMscUls889urfHHVnyjf0Uz+lTR9EwGHhMwXd8xLcC rnO+autspbX/noeLXSe4gXzBTbVEbCahivAuVZfDmsxZkUZl+Z3lNiYMfs2LdNlXKCoL WI7K/+L+YAHU61Ehtww8a9lMSJ99K7Jl5hdO5mmWEqmOwf5J0J0q6knaaCfHZgYJc+gv T0XMR8Yuc9L0QvXAluBsGmnXrFyIge6mnU6VFtdP/F3dPfiDchpPjjnOMGVAoV6/6ANB QAtzyjFe0RRiWq5W1dfpvk/IK+QI8nMJHFIWONFs0SVskdHM1PO9bovVzTd7saJyYTfU EDWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=dFgxTimLFzoMlhqSiAL9/HhO3S0b/O2ri7x/cORyNI4=; b=YRfpTSTMz9dG7/TUW5ZVGeKi9DXlM1A0FxhzyX1LkHcMFUdMEr3uK8fjLIC8mAPqPF ueg20bCXZacgjYYtfrtcHNAB8Nim1CFYcz62gBtfbb+cr3bHTgc7u4FlO+MKcxkx8GiM tVxGWUq9irkmVlMMx4v9xIPL1M4I6F9fslCkFM9HOZqpS5yMBtOUHdU0tE3Sg5enmUcD lpXjRyLF8qACOTzxlH58PQeBC0izZGe/zVOzhODivhIapQcJPdDW5jrNaS6R40EH9Mlf z/HcIvQeawz186z1OS0xNQEJklRE3Q6tgzWYwv0YfPa4y4k4ursr1DCdTzt9iu0W/BM5 YcAA== X-Gm-Message-State: AD7BkJJTW192a1PIof2a6CmJKI0d+ww5TLCnWujHD9EuJvujw3eECZEJlu3BrmaJ/i/5Cw== X-Received: by 10.140.30.8 with SMTP id c8mr55234005qgc.67.1459972809942; Wed, 06 Apr 2016 13:00:09 -0700 (PDT) Received: from [192.168.1.9] ([186.60.153.174]) by smtp.gmail.com with ESMTPSA id u102sm1942443qge.27.2016.04.06.13.00.07 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 13:00:08 -0700 (PDT) From: Bryan Ford X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_A90096DD-D03D-4068-851E-0B41E3249003"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 6 Apr 2016 17:00:04 -0300 Message-Id: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> To: openpgp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:00:13 -0000 --Apple-Mail=_A90096DD-D03D-4068-851E-0B41E3249003 Content-Type: multipart/alternative; boundary="Apple-Mail=_43D229CA-DB22-4DC7-8068-9668632E3392" --Apple-Mail=_43D229CA-DB22-4DC7-8068-9668632E3392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the mailing list bomb, but I wanted to get a few more thoughts = on the list while they=E2=80=99re still fresh. Moving back to the = question of what the =E2=80=9Cfingerprint scheme=E2=80=9D itself might = look like (the function that takes an octet-string and produces an = ASCII-string), which may not really be OpenPGP-specific=E2=80=A6 One of the potential goals that=E2=80=99s been discussed is to give = users some form of =E2=80=9Cfingerprint-mining protection=E2=80=9D, or = defense against attackers mining for keys with similar-looking = fingerprints. This could potentially be provided either by playing with = =E2=80=9Cwhat gets fingerprinted=E2=80=9D (the topic of the E-mail I = just posted), or by playing with the fingerprint scheme itself (the = topic of this E-mail). Here=E2=80=99s one specific idea for a fingerprint scheme with = configurable mining protection, which builds on ideas suggested earlier = by Christian Huitema and Phillip Hallam-Baker and others: * Key creation: OpenPGP implementation first picks a hardness parameter = H determining level of mining protection. Implementations could provide = a reasonable default for this, while allowing power-users to tweak it if = they want. Iterate the following loop until successful: 1. Generate a public/private key-pair. Call this public-key K. 2. Take a hash of K and some domain-separation context string, = yielding a =E2=80=9Cnonce=E2=80=9D N. 3. Use nonce N as the nonce input in an Argon2 proof-of-work, = using otherwise fixed, =E2=80=9Creasonable=E2=80=9D Argon2 configuration = parameters. 3. Compute a SHA-512 hash based on K and this Argon2 = proof-of-work; this is the =E2=80=9Cpre-fingerprint=E2=80=9D. 4. Unless the resulting pre-fingerprint has exactly H leading = bits/bytes, go back to step 1, retrying with a fresh keypair. 5. Form the fingerprint to present to the user as a one-digit = encoding of H followed by an encoding of the last 256 bits of the = pre-fingerprint. * Fingerprint verification/recomputation on PGP key import: take = public-key K, hash it as above, compute Argon2 nonce N, run a single = Argon2 PoW round, verify the resulting SHA-512 against the proposed = fingerprint. Compute correct resulting fingerprint based on the number = of leading zero-bits found in the hash and the last 256 bits of the = SHA512 output. The potentially beneficial properties of this approach are: - Once the public/private key pair is created, the fingerprint depends = on the public key and nothing else: i.e., it is =E2=80=9Ckey-canonical=E2=80= =9D, as per the preference DKG expressed, keeping things simple. - Users (and OpenPGP implementations) can configure the hardness = parameter, in particular gradually increasing it over time, so that the = difficulty of fingerprint-mining attacks for newly-created keys can keep = pace with the increasing computational abilities of attackers. Average = users shouldn=E2=80=99t necessarily be expected to see or be aware of = this at all; they just get keys with stronger fingerprints when they use = newer software/machines to generate them. - The use of an Argon2 PoW step in the =E2=80=9Cinner loop=E2=80=9D = makes it more difficult for attackers to do fingerprint-mining just by = being very good at computing SHAs - e.g., as PHB mentioned, by using a = big bank of GPUs or a bunch of repurposed Bitcoin mining hardware. We = don=E2=80=99t want to make all fingerprint-verifiers solve a =E2=80=9Cbig=E2= =80=9D Argon2 PoW (because the receiver might be a smartphone with = limited memory for example), but even just including a small/moderate = Argon2 PoW in the key-creation mining loop might reduce a typical = attacker=E2=80=99s advantage considerably. Just as an aside, this hybrid between Argon2 and Bitcoin-style mining is = really just kind of a =E2=80=9Cpoor-man=E2=80=99s=E2=80=9D solution to = what we really want, which is an easily-verifiable =E2=80=9Cslow hash=E2=80= =9D as Arjen Lenstra=E2=80=99s group proposed in this paper: = https://eprint.iacr.org/2015/366 Cheers Bryan --Apple-Mail=_43D229CA-DB22-4DC7-8068-9668632E3392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry for the mailing list bomb, but I wanted to get a few = more thoughts on the list while they=E2=80=99re still fresh. =  Moving back to the question of what the =E2=80=9Cfingerprint = scheme=E2=80=9D itself might look like (the function that takes an = octet-string and produces an ASCII-string), which may not really be = OpenPGP-specific=E2=80=A6  

One of the potential goals that=E2=80=99s been discussed is = to give users some form of =E2=80=9Cfingerprint-mining protection=E2=80=9D= , or defense against attackers mining for keys with similar-looking = fingerprints.  This could potentially be provided either by playing = with =E2=80=9Cwhat gets fingerprinted=E2=80=9D (the topic of the E-mail = I just posted), or by playing with the fingerprint scheme itself (the = topic of this E-mail).

Here=E2=80=99s one specific idea for a fingerprint scheme = with configurable mining protection, which builds on ideas suggested = earlier by Christian Huitema and Phillip Hallam-Baker and = others:

* Key = creation:  OpenPGP implementation first picks a hardness parameter = H determining level of mining protection. Implementations could provide = a reasonable default for this, while allowing power-users to tweak it if = they want.  Iterate the following loop until successful:

1. = Generate a public/private key-pair.  Call this public-key = K.
2. Take a hash of K and some = domain-separation context string, yielding a =E2=80=9Cnonce=E2=80=9D = N.
3. Use nonce N as the nonce = input in an Argon2 proof-of-work, using otherwise fixed, = =E2=80=9Creasonable=E2=80=9D Argon2 configuration parameters.
= 3. Compute a SHA-512 hash based on K and this Argon2 = proof-of-work; this is the =E2=80=9Cpre-fingerprint=E2=80=9D.
= 4. Unless the resulting pre-fingerprint has exactly H leading = bits/bytes, go back to step 1, retrying with a fresh keypair.
= 5. Form the fingerprint to present to the user as a one-digit = encoding of H followed by an encoding of the last 256 bits of the = pre-fingerprint.

* Fingerprint = verification/recomputation on PGP key import: take public-key K, hash it = as above, compute Argon2 nonce N, run a single Argon2 PoW round, verify = the resulting SHA-512 against the proposed fingerprint.  Compute = correct resulting fingerprint based on the number of leading zero-bits = found in the hash and the last 256 bits of the SHA512 output.

The potentially = beneficial properties of this approach are:

- Once the public/private key pair is = created, the fingerprint depends on the public key and nothing else: = i.e., it is =E2=80=9Ckey-canonical=E2=80=9D, as per the preference DKG = expressed, keeping things simple.

- Users (and OpenPGP implementations) = can configure the hardness parameter, in particular gradually increasing = it over time, so that the difficulty of fingerprint-mining attacks for = newly-created keys can keep pace with the increasing computational = abilities of attackers.  Average users shouldn=E2=80=99t = necessarily be expected to see or be aware of this at all; they just get = keys with stronger fingerprints when they use newer software/machines to = generate them.

-= The use of an Argon2 PoW step in the =E2=80=9Cinner loop=E2=80=9D makes = it more difficult for attackers to do fingerprint-mining just by being = very good at computing SHAs - e.g., as PHB mentioned, by using a big = bank of GPUs or a bunch of repurposed Bitcoin mining hardware.  We = don=E2=80=99t want to make all fingerprint-verifiers solve a =E2=80=9Cbig=E2= =80=9D Argon2 PoW (because the receiver might be a smartphone with = limited memory for example), but even just including a small/moderate = Argon2 PoW in the key-creation mining loop might reduce a typical = attacker=E2=80=99s advantage considerably.

Just as an aside, this hybrid between = Argon2 and Bitcoin-style mining is really just kind of a = =E2=80=9Cpoor-man=E2=80=99s=E2=80=9D solution to what we really want, = which is an easily-verifiable =E2=80=9Cslow hash=E2=80=9D as Arjen = Lenstra=E2=80=99s group proposed in this paper: https://eprint.iacr.org/2015/366 

Cheers
Bryan

= --Apple-Mail=_43D229CA-DB22-4DC7-8068-9668632E3392-- --Apple-Mail=_A90096DD-D03D-4068-851E-0B41E3249003 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBWrFAAoJEGt1rlrP7+d/eIIP/iNEYfaVZ6I0w1/jJNOmq8sC Wv+Gy8KbOWdmWxi8bX9+9qHgby3FcFYSvdlHqfOgD5Gr9nGKnv8ghyFcV8Vm67hH rcBRjaNpq1wsOHY00re+gbK6gmExlIfDWnUPkkxrXDQ4cDHWnpHy1nXOGukL8w3M I6iYJ3EEQlmOo7lcb7cnP10YdbLeP2qChhjZLtpQGnyzvCUuh/BAIoTUupPQgS7V wu7aORLQ6yXz/U31QEeoAmmcOq0/Lua1wLjVE+KnLEwzkWlYbaAa59aX90c5QZ3o RGab0z/ZuXsdZKBz5eqwfub7IcqSOWqnrUXfw3JNbBBqUma0RB8RCQcBmumZYIyO 5eqxrCytpcXLH8UQ8UJ4yaH+XX1yNnYm+OpVE0a8rRCW345sZhJP5fNWrROwEtIt KI0xxuqlGgWq5jRgbmD0GOBe09GJ5gqXsPK1cHjQEsbmODD/aGj4U4Jjit7fdh8L M9oAwd+CLbn3uLUzAOBq6+WUH9WtWgBcFYQawuroeKVIMCygexsL58T0W2t1tgy4 0VGiLScC3K7uayWtSFgliS8JNsK3HtqyE54NMVFhQdnyLjOnf9r+erJcjz7zEuZo 1MdujrTnKB6I0JeVwC9+Q+z1TXQFsIgFhgark32Xb67sO9T0pjPy3ceGTLQQeUWF WdxgCDspgGk1hvwd8qNm =fuIa -----END PGP SIGNATURE----- --Apple-Mail=_A90096DD-D03D-4068-851E-0B41E3249003-- From nobody Wed Apr 6 15:38:10 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7BA12D5D9 for ; Wed, 6 Apr 2016 15:38: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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easc0aeW_I2l for ; Wed, 6 Apr 2016 15:38:07 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DA12D6C7 for ; Wed, 6 Apr 2016 15:38:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id C3B59942D093; Wed, 6 Apr 2016 15:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmIOkotwtyqB; Wed, 6 Apr 2016 15:37:54 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 9A498942D038; Wed, 6 Apr 2016 15:37:51 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 06 Apr 2016 15:37:54 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 06 Apr 2016 15:37:54 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: Date: Wed, 6 Apr 2016 15:37:51 -0700 Message-Id: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> References: To: Bryan Ford X-Mailer: Apple Mail (2.3124) Content-Type: multipart/alternative; boundary="Apple-Mail=_BDF4CF8E-F174-4D39-893F-487B9F4D4893" Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:38:10 -0000 --Apple-Mail=_BDF4CF8E-F174-4D39-893F-487B9F4D4893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 6, 2016, at 12:20 PM, Bryan Ford wrote: >=20 > * PGP - S/MIME Signed by an unverified key: 04/06/2016 at 12:20:08 PM > Getting back to DKG=E2=80=99s question of whether the Unix = creation-timestamp should be included in the octet-stream passed to a = (future) OpenPGP fingerprint scheme=E2=80=A6 I want to generalize the = question into a choice between three options: >=20 > 1. The fingerprint covers *only* the public-key material itself, in a = verifiably and enforceably canonical form. >=20 > 2. The fingerprint covers the public-key material and some other = fixed-format stuff like version info and Unix timestamp, as in rfc4880. >=20 > 3. The fingerprint covers the public-key material and some extensible = variable-length information, e.g., parameters the key-holder specifies = in its self-signed cert at key creation time. I've gone back and forth on this over the years. I finally ended up with = #2 (or #3) being right enough. If you do #1, then you make it so that you can't use the same key for = multiple purposes. You can't for example use it for aliases and nyms. I = think #1 is a bad idea because it tends to turn the fingerprint into a = tracking identifier and I think that making your crypto be implicitly = tracking-friendly is a bad idea. So let's talk about #2 and #3 as somewhere on a continuum of saying that = the fingerprint is a computable database identifier that provides some = onewayness from key to fingerprint. The way OpenPGP presently does it is kinda meh. It achieves the goal = that knowing a fingerprint can find a key, but is merely onto, not = one-to-one. It is, however, the way that it is. If you change it, you end up with unknown breakage. I also don't see a = *goal*. What problem are you trying to solve? I recognize that creating = a new fingerprint algorithm provides an opportunity, but I have to ask = why. If you specify extra data to be thrown in, it gives the future more = places to attack fingerprints in clever ways. Whatever algorithm you = pick, it ought to be simple. I can see perhaps that you might want to = put some "salt" into it, but if you do, it ought to be relatively small, = and if it is variable-length, you need to add in the length as well. However, despite not being able to say a lot of good things about #2 = (the existing one), it is the existing one. Arguably one should keep it = unless there's stated goodness to be had. Jon --Apple-Mail=_BDF4CF8E-F174-4D39-893F-487B9F4D4893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 6, 2016, at 12:20 PM, Bryan Ford <brynosaurus@gmail.com> wrote:

* PGP - S/MIME Signed by an unverified key: 04/06/2016 at 12:20:08 PM
Getting back to DKG=E2=80=99s question of whether the Unix = creation-timestamp should be included in the octet-stream passed to a = (future) OpenPGP fingerprint scheme=E2=80=A6  I want to generalize = the question into a choice between three options:

1. The fingerprint covers *only* the = public-key material itself, in a verifiably and enforceably canonical = form.

2. The fingerprint covers the public-key material and some = other fixed-format stuff like version info and Unix timestamp, as in = rfc4880.

3. The fingerprint covers the public-key material and some = extensible variable-length information, e.g., parameters the key-holder = specifies in its self-signed cert at key creation = time.

I've gone back and forth on this over the years. I = finally ended up with #2 (or #3) being right enough.

If you do #1, then you make it so that = you can't use the same key for multiple purposes. You can't for example = use it for aliases and nyms. I think #1 is a bad idea because it tends = to turn the fingerprint into a tracking identifier and I think that = making your crypto be implicitly tracking-friendly is a bad = idea.

So let's = talk about #2 and #3 as somewhere on a continuum of saying that the = fingerprint is a computable database identifier that provides some = onewayness from key to fingerprint.

The way OpenPGP presently does it is = kinda meh. It achieves the goal that knowing a fingerprint can find a = key, but is merely onto, not one-to-one. It is, however, the way that it = is.

If you = change it, you end up with unknown breakage. I also don't see a *goal*. = What problem are you trying to solve? I recognize that creating a new = fingerprint algorithm provides an opportunity, but I have to ask = why.

If you = specify extra data to be thrown in, it gives the future more places to = attack fingerprints in clever ways. Whatever algorithm you pick, it = ought to be simple. I can see perhaps that you might want to put some = "salt" into it, but if you do, it ought to be relatively small, and if = it is variable-length, you need to add in the length as well.

However, despite not = being able to say a lot of good things about #2 (the existing one), it = is the existing one. Arguably one should keep it unless there's stated = goodness to be had.

= Jon


= --Apple-Mail=_BDF4CF8E-F174-4D39-893F-487B9F4D4893-- From nobody Wed Apr 6 15:39:55 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0172912D192 for ; Wed, 6 Apr 2016 15:39:55 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL2bPn8lO0Nf for ; Wed, 6 Apr 2016 15:39:53 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id CFF3212D134 for ; Wed, 6 Apr 2016 15:39:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 7727C942D1E4; Wed, 6 Apr 2016 15:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3+CIRyHm9QY; Wed, 6 Apr 2016 15:39:52 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 48534942D1CF; Wed, 6 Apr 2016 15:39:52 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 06 Apr 2016 15:39:52 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 06 Apr 2016 15:39:52 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> Date: Wed, 6 Apr 2016 15:39:52 -0700 Message-Id: <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> To: Bryan Ford X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:39:55 -0000 I don't get it. What problem are you trying to solve. Along with the = previous note -- the fingerprint is in fact merely a hash of the key. = It's a handle you can use in a database to identify the key with a fixed = string. That's it. Jon From nobody Wed Apr 6 23:40:27 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1412D56C for ; Wed, 6 Apr 2016 23:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x70b71ze0MRg for ; Wed, 6 Apr 2016 23:40:22 -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 E7F0512D56A for ; Wed, 6 Apr 2016 23:40:21 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ao3c2-0005ZA-Rf for ; Thu, 07 Apr 2016 08:40:18 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ao3bd-0005ob-RG; Thu, 07 Apr 2016 08:39:53 +0200 From: Werner Koch To: Bryan Ford References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Bryan Ford , openpgp@ietf.org Date: Thu, 07 Apr 2016 08:39:53 +0200 In-Reply-To: <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> (Bryan Ford's message of "Wed, 6 Apr 2016 15:15:59 -0300") Message-ID: <87egahvs5i.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 06:40:25 -0000 On Wed, 6 Apr 2016 20:15, brynosaurus@gmail.com said: > 1. What fingerprint scheme(s) should OpenPGP move to going forward? A SHA-256 hash of the artificial OpenPGP key packet as we use it right now. The open question is whether to=20 - include a creation timestamp, - a timestamp but fixed to 0 (as Google End-to-End does), - some other static info data to surely separate that fingerprint from other protocols fingerprint using the same key (i.e. token based) - no creation timestamp The rationale for SHA-256 is that this is the only fast algorithm on all platforms. A related question is how to identify the new fingerprint scheme in OpenPGP objects which store a fingerprint: - Implicit by the length of the fingerprint, - or by a prefix byte with the hash algorithm, - or by a prefix byte with the key version number, - or by a prefix byte with the length of the fingerprint. All but the first options allow to store a truncated fingerprint in some object (the forthcoming Issuer-Fpr signature subpacket, the updated Revocation Key subpacket). I tend to prefer the second option because this reflects existing usage: 5.2.3.25. Signature Target (1 octet public-key algorithm, 1 octet hash algorithm, N octets hash) The public-key algorithm byte does not make much sense, though. > 2. What exactly should the OpenPGP =E2=80=9Capplication=E2=80=9D fingerpr= int with that scheme? > > To clarify, I propose to define a =E2=80=9Cfingerprint scheme=E2=80=9D as= an algorithm > that takes a raw octet string and produces an ASCII string of some You describe how a fingerprint is presented to the user. This has been out of scope for OpenPGP. Implementations have settled for a de-facto standard outside of the protocol. I think we should keep it this way and at best give only a suggestion for a human readable format. Humans are bad at comparing fingerprints; this should in general be left to the software and additional protocols to establish a connection between an identity and a key/fingerprint. Shalom-Salam, Werner --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 7 04:03:03 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2312D70B for ; Thu, 7 Apr 2016 04:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6vhEGK60UFG for ; Thu, 7 Apr 2016 04:02:55 -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 E556712D14A for ; Thu, 7 Apr 2016 04:02:54 -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=1460026975; x=1491562975; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ID9jUTh08zsSKmru2Y03n5P3mhI1AxmKpxu1rQ1sV3A=; b=MyXjO+mIysJgh8tJfA4uV4zljLjTpNFIKbXDik3Q7L2E5nWkciVBo59D h2gzC/4fKBl2CUGRzZRguTOzd2Bg2RKcgtcmQgMhLDvVUr0MQi4ZD5POj ptBfzR01sOEW7plGPpajrwnzaputMmJ1TGz0r29zUw/Q/flWLcVNp42cK ipwEKm0sVKEPkXw3J1zjvF8s6/NLkRITAtiMV3nPz5auzmH70aF5AX0Bz aiCZtblfjrTrdBer8lamX2ROv9khS9aYw7+ibdLXDbmDGjdPqlOs6bkgE +U6NrE1X7gLHiq32UJhIz7b2UbqnfNxylB+zG57FPVBBVwUt2fYqT2avB Q==; X-IronPort-AV: E=Sophos;i="5.24,449,1454929200"; d="scan'208";a="78821404" 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/AES256-SHA; 07 Apr 2016 23:02:52 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Thu, 7 Apr 2016 23:02:52 +1200 From: Peter Gutmann To: Bryan Ford , "openpgp@ietf.org" Thread-Topic: [openpgp] Fingerprint schemes versus what to fingerprint Thread-Index: AQHRkDB2Lsq2Mh4ysUu+sJ1BpPuIG59+WZUf Date: Thu, 7 Apr 2016 11:02:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net>, <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> In-Reply-To: <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 11:03:03 -0000 Bryan Ford writes:=0A= =0A= >DKG brought up the question of whether that octet-string should still=0A= >include the Unix timestamp like it currently does.=0A= =0A= Definitely not. What you want is a means of generating a unique lookup key= =0A= (e.g. for a database or hash table) that locates a public key. By mixing a= =0A= nonce, the timestamp, into the calculation, you lose the uniqueness, and in= =0A= fact the locatability, because the search key is no longer just a hash of t= he=0A= public key but a hash of the public key and some other metadata that you ma= y=0A= or may not have.=0A= =0A= Peter.=0A= From nobody Thu Apr 7 07:36:08 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06A12D816 for ; Thu, 7 Apr 2016 07:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTdOWgH0Glqy for ; Thu, 7 Apr 2016 07:36:05 -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 8B1C712D95C for ; Thu, 7 Apr 2016 07:20:21 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aoAnD-0000AW-82 for ; Thu, 07 Apr 2016 16:20:19 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aoAkt-00007V-Rs; Thu, 07 Apr 2016 16:17:55 +0200 From: Werner Koch To: Peter Gutmann References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@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: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Peter Gutmann , Bryan Ford , "openpgp\@ietf.org" Date: Thu, 07 Apr 2016 16:17:55 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 7 Apr 2016 11:02:50 +0000") Message-ID: <87lh4psdt8.fsf@wheatstone.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" , Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:36:07 -0000 On Thu, 7 Apr 2016 13:02, pgut001@cs.auckland.ac.nz said: > fact the locatability, because the search key is no longer just a hash of the > public key but a hash of the public key and some other metadata that you may > or may not have. In other words: With the current fingerprint scheme it is not possible to find the fingerprint for given public key parameters. For example this inhibits the use of arbitrary smartcards because there is no way to get the fingerprint form the smartcard data. To help with that we had to add creation timestamp fields to the OpenPGP smartcard specs. For other smartcards special hacks are required. Some expressed concerns about cross-protocol attacks w/o an OpenPGP specific fingerprint. This could be fixed by including a few _constant_ magic bytes into the OpenPGP fingerprint computation. Similar to the yesterday proposed signature prefix to distinguish OpenPGP signatures from signatures uses by other protocols. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 7 07:39:01 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34212D1C8 for ; Thu, 7 Apr 2016 07:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn3ZlBOwVKfI for ; Thu, 7 Apr 2016 07:38:51 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 8EE3912D1AB for ; Thu, 7 Apr 2016 07:24:22 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id c6so64256976qga.1 for ; Thu, 07 Apr 2016 07:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=x28H+L46L/YDNyIzw87rmrArahRAFU9yc3Yz0ICJqJo=; b=lCDcCtW5zq/8/QR3Yf5E7SPZyFE3y2UgemTRwHiX35yw81N8+Np6spl6+HafXMOxU5 9fLJ20+0+rIV8w7cpvC90Id9xpJlzGBUGZv9NlC5+ju0z1UJRh32+UIq40f4HUyO4llv cp9wXSQjwbmYylwcvLSNPi0rh69Qm53t50kY+NAKVjj3RXDbZQOLVBKMsuL+iQWwjmsZ Upbb3sT6Q21U7+SgaysESp9ba5Orfa/bWxVko1BHvSfgK3dJfkYRtyAME7Z1XVK7CFWX 1RRPo9x4MyfbZJMlnLfthXwlaXdcYwNF3sOl/Tm6kMj7yQQF33yUhk2nOU5M1RPvR//L 88lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=x28H+L46L/YDNyIzw87rmrArahRAFU9yc3Yz0ICJqJo=; b=WyyKFwpDmjqHISgzDfWxUAyJNfLkYde9yyGomnYG1BzN0dtDM06e0SFSTmdCC7NTBH P66L2kxNEQUdYUe2p5VTdpmYsNA+GgBLeMAptTM8gqhYaEjEH2EaJ5cUt2PUkFwO4Hds OUgAZhs0CtOR0F15EBjsf+90PVYAL1j7ZUhMxYRcoEC12ihqPGCqq9pL7eExpnlxAI53 IH4pRgFQzDgd9cuTBVBL//LqL5ZoOBvi+dR9Ch8Bzsau2qGRyL2js0bXRbab0dGYWUOo Tznrsg3rmmiP14uraE/X2UVr2npbRhLQnXSRtiJ5YCQmfb1AFtVxjyp6Y2UfmB39y3/t U9mQ== X-Gm-Message-State: AD7BkJIKbO8tDe3pI7MI2s/njnv+9TKeJWHtrqfkCMUE4l4wtwWZpTXaheq6iyjfsHdhLQ== X-Received: by 10.140.98.163 with SMTP id o32mr4139116qge.46.1460039061685; Thu, 07 Apr 2016 07:24:21 -0700 (PDT) Received: from [192.168.1.194] ([201.177.50.160]) by smtp.gmail.com with ESMTPSA id w32sm3490244qge.12.2016.04.07.07.23.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 07:24:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_57D2F640-8DF0-476F-8D9C-07E1A5202F8C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> Date: Thu, 7 Apr 2016 11:22:19 -0300 Message-Id: <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:38:54 -0000 --Apple-Mail=_57D2F640-8DF0-476F-8D9C-07E1A5202F8C Content-Type: multipart/alternative; boundary="Apple-Mail=_63E22DBA-6E02-46F8-954B-A191A81843F9" --Apple-Mail=_63E22DBA-6E02-46F8-954B-A191A81843F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jon, thanks for the comments. > On Apr 6, 2016, at 7:37 PM, Jon Callas wrote: >> On Apr 6, 2016, at 12:20 PM, Bryan Ford > wrote: >>=20 >> * PGP - S/MIME Signed by an unverified key: 04/06/2016 at 12:20:08 PM >> Getting back to DKG=E2=80=99s question of whether the Unix = creation-timestamp should be included in the octet-stream passed to a = (future) OpenPGP fingerprint scheme=E2=80=A6 I want to generalize the = question into a choice between three options: >>=20 >> 1. The fingerprint covers *only* the public-key material itself, in a = verifiably and enforceably canonical form. >>=20 >> 2. The fingerprint covers the public-key material and some other = fixed-format stuff like version info and Unix timestamp, as in rfc4880. >>=20 >> 3. The fingerprint covers the public-key material and some extensible = variable-length information, e.g., parameters the key-holder specifies = in its self-signed cert at key creation time. >=20 > I've gone back and forth on this over the years. I finally ended up = with #2 (or #3) being right enough. >=20 > If you do #1, then you make it so that you can't use the same key for = multiple purposes. You can't for example use it for aliases and nyms. I = think #1 is a bad idea because it tends to turn the fingerprint into a = tracking identifier and I think that making your crypto be implicitly = tracking-friendly is a bad idea. That=E2=80=99s a really good point - I definitely agree with the = desirability of making fingerprints less useful as tracking identifiers. = On the other hand, one might argue that there are other ways to address = this, e.g., by just having separate keys (or subkeys?) representing = nyms. If you *really* want your nyms to be unlinkable to each other it = doesn=E2=80=99t seem avoidable that they=E2=80=99ll need to be based on = separate keys and not just different fingerprints for the same key. > So let's talk about #2 and #3 as somewhere on a continuum of saying = that the fingerprint is a computable database identifier that provides = some onewayness from key to fingerprint. >=20 > The way OpenPGP presently does it is kinda meh. It achieves the goal = that knowing a fingerprint can find a key, but is merely onto, not = one-to-one. It is, however, the way that it is. >=20 > If you change it, you end up with unknown breakage. I also don't see a = *goal*. What problem are you trying to solve? I recognize that creating = a new fingerprint algorithm provides an opportunity, but I have to ask = why. >=20 > If you specify extra data to be thrown in, it gives the future more = places to attack fingerprints in clever ways. Agreed, and this consideration definitely seems to argue for a strict = 1-to-1 fingerprint-to-key relationship. > Whatever algorithm you pick, it ought to be simple. I can see perhaps = that you might want to put some "salt" into it, but if you do, it ought = to be relatively small, and if it is variable-length, you need to add in = the length as well. >=20 > However, despite not being able to say a lot of good things about #2 = (the existing one), it is the existing one. Arguably one should keep it = unless there's stated goodness to be had. There=E2=80=99s nothing wrong with keeping the existing format as a = legacy thing, but if we=E2=80=99re not actually going to do anything = with the timestamp - and clearly we can=E2=80=99t trust it for anything = anyway - I=E2=80=99d be in favor of either eliminating it or just fixing = it to 0 as Werner mentioned Google End-to-End does. B > Jon --Apple-Mail=_63E22DBA-6E02-46F8-954B-A191A81843F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Jon, thanks for the comments.

On = Apr 6, 2016, at 7:37 PM, Jon Callas <jon@callas.org> wrote:
On Apr 6, 2016, at 12:20 PM, Bryan Ford <brynosaurus@gmail.com> wrote:

* = PGP - S/MIME Signed by an unverified key: 04/06/2016 at 12:20:08 PM
Getting back to DKG=E2=80=99s question of whether = the Unix creation-timestamp should be included in the octet-stream = passed to a (future) OpenPGP fingerprint scheme=E2=80=A6  I want to = generalize the question into a choice between three options:

1. The fingerprint = covers *only* the public-key material itself, in a verifiably and = enforceably canonical form.

2. The fingerprint covers the = public-key material and some other fixed-format stuff like version info = and Unix timestamp, as in rfc4880.

3. The fingerprint covers the = public-key material and some extensible variable-length information, = e.g., parameters the key-holder specifies in its self-signed cert at key = creation time.

I've gone back and forth on = this over the years. I finally ended up with #2 (or #3) being right = enough.

If you = do #1, then you make it so that you can't use the same key for multiple = purposes. You can't for example use it for aliases and nyms. I think #1 = is a bad idea because it tends to turn the fingerprint into a tracking = identifier and I think that making your crypto be implicitly = tracking-friendly is a bad idea.

That=E2=80=99s a really good point - I definitely = agree with the desirability of making fingerprints less useful as = tracking identifiers.  On the other hand, one might argue that = there are other ways to address this, e.g., by just having separate keys = (or subkeys?) representing nyms.  If you *really* want your nyms to = be unlinkable to each other it doesn=E2=80=99t seem avoidable that = they=E2=80=99ll need to be based on separate keys and not just different = fingerprints for the same key.

So let's talk about #2 and #3 as = somewhere on a continuum of saying that the fingerprint is a computable = database identifier that provides some onewayness from key to = fingerprint.

The = way OpenPGP presently does it is kinda meh. It achieves the goal that = knowing a fingerprint can find a key, but is merely onto, not = one-to-one. It is, however, the way that it is.

If you change it, you end up with = unknown breakage. I also don't see a *goal*. What problem are you trying = to solve? I recognize that creating a new fingerprint algorithm provides = an opportunity, but I have to ask why.

If you specify extra data to be thrown = in, it gives the future more places to attack fingerprints in clever = ways.

Agreed, = and this consideration definitely seems to argue for a strict 1-to-1 = fingerprint-to-key relationship.

Whatever algorithm you pick, it ought = to be simple. I can see perhaps that you might want to put some "salt" = into it, but if you do, it ought to be relatively small, and if it is = variable-length, you need to add in the length as well.

However, despite not being able to say = a lot of good things about #2 (the existing one), it is the existing = one. Arguably one should keep it unless there's stated goodness to be = had.

There=E2=80=99= s nothing wrong with keeping the existing format as a legacy thing, but = if we=E2=80=99re not actually going to do anything with the timestamp - = and clearly we can=E2=80=99t trust it for anything anyway - I=E2=80=99d = be in favor of either eliminating it or just fixing it to 0 as Werner = mentioned Google End-to-End does.

B

= Jon

= --Apple-Mail=_63E22DBA-6E02-46F8-954B-A191A81843F9-- --Apple-Mail=_57D2F640-8DF0-476F-8D9C-07E1A5202F8C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDcxNDIyMjBaMCMGCSqGSIb3DQEJBDEWBBT2D+FyRmOKuRmO0kvd4aPqIcDKzTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAXCIvrJdnhqEdFlkGk1Td15tX/sbCLHlUNbXU1Q6nqwQ3Uewcq+Oiy+NMiASFm/ew fZPZACfM7g5aZHR4rjj9QuyrvY8sHjYwfgUnI3sDMR26pZWEuhJK1jpMd0lYscGQWGMpMVQ0e2ft sWaapBHgiDBGwOh6TJCokg9auJQmexMRVNjTsrNLg/uwoTEqptcJEleGoaqTfo0q+t30RxOtO3Dl v8Fy8TsS/77jnu6DTXn83+b071EAwCU16Wg8kbPIpxYP+yrQClqwRKEQ/Qmp51X0c8kbEGrauv/d uFOrpt6tYAZOcDvJ1dqM39siqi+B99m8Vdv6KZtyrNEz6jyn1gAAAAAAAA== --Apple-Mail=_57D2F640-8DF0-476F-8D9C-07E1A5202F8C-- From nobody Thu Apr 7 07:56:42 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45F12D9AB for ; Thu, 7 Apr 2016 07:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3m1H5bBbCOv for ; Thu, 7 Apr 2016 07:56:38 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 7651B12D558 for ; Thu, 7 Apr 2016 07:44:35 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id k135so27722972qke.0 for ; Thu, 07 Apr 2016 07:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Y4xid66+F7jSQ3GSdBw84L+C3i4dGLl2905Vtw49j4Q=; b=Y34SUcUvbNksIRWKrWfT7R1vA8jaZAEkzkjjmtMV5ejJcV2aT+t2yEqb+Dw8gl8YKY kzcIDMdjQwlesbtAqY/mmeImWjcEmFpCY2GMYaL/fXdlP+27gWpz0jLGh5NDQzDYkWUz 5qQET+En7P6M5RDfySTAf/DiNlvPdzF7kJ6H2d/xHxIaFk4s7iSDY8lRrdGkdTXsllVZ osQwPot3UTkElBFSDaajVCqYsLLc5RFUxGTfmEB/z1hadyeJqGoSA1V63HxO2zR5PXvg iJhZ+4kkWazdyilnFjT6/nqMAI+KT6pa/2Zkeih/VTA8uh+XUddFFmaLYzkPOTP+52RH j2Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Y4xid66+F7jSQ3GSdBw84L+C3i4dGLl2905Vtw49j4Q=; b=SEYvHXib6t9VRIbquz9ZNr159NXHudHZELe6WjlkcgC9MNB6WSjBoUhSb91ifYzSW4 VBLrRAnnQWbGntm2dzY2c2b4bzUsC8fSXlptfLI1fWyGh2nb7VkEVcfSI+xY2UrDC9Pc ksCri+OaKnBddLVa9Sv3Z1pYXa1PrFndRR7Ew4U1ubbNRYDA/VF0rjJvWm4upVyEP2WC rCRKVflsUQOTQyKGIusJlb2YzmSm3ux8DjC4b81wPjrnTWs756eFmY2In0zKmWhI+V4w 5qC0Poe+HGDI6GfY82cwjghe7+gFVnMLK+JNtuqi5knY/3pHpETrit4j5b8HEq1YLKuh Lp2g== X-Gm-Message-State: AD7BkJJox2d3LRC0nuvkDbZckBpedplH1vRhd875b2gkAMytFtq9KIPBN2CbwDkJIGtktA== X-Received: by 10.55.82.6 with SMTP id g6mr4185936qkb.40.1460040274590; Thu, 07 Apr 2016 07:44:34 -0700 (PDT) Received: from [192.168.1.194] ([201.177.50.160]) by smtp.gmail.com with ESMTPSA id u63sm594967qhu.18.2016.04.07.07.44.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 07:44:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_714D4858-8321-453A-BCF1-3D1F6DAF23A8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <87egahvs5i.fsf@wheatstone.g10code.de> Date: Thu, 7 Apr 2016 11:44:11 -0300 Message-Id: <333ABB52-E84C-4039-80AE-01ABE65A91D7@gmail.com> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <87egahvs5i.fsf@wheatstone.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:56:40 -0000 --Apple-Mail=_714D4858-8321-453A-BCF1-3D1F6DAF23A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2016, at 3:39 AM, Werner Koch wrote: >=20 > On Wed, 6 Apr 2016 20:15, brynosaurus@gmail.com said: >=20 >> 1. What fingerprint scheme(s) should OpenPGP move to going forward? >=20 > A SHA-256 hash of the artificial OpenPGP key packet as we use it right > now. The open question is whether to=20 >=20 > - include a creation timestamp, > - a timestamp but fixed to 0 (as Google End-to-End does), > - some other static info data to surely separate that fingerprint = from > other protocols fingerprint using the same key (i.e. token based) > - no creation timestamp >=20 > The rationale for SHA-256 is that this is the only fast algorithm on = all > platforms. What about Blake2? If OpenPGP will be using Argon2 for password = hashing, then all implementations will need to have a Blake2 = implementation anyway because Argon2 builds on Blake2. > A related question is how to identify the new fingerprint scheme in > OpenPGP objects which store a fingerprint: >=20 > - Implicit by the length of the fingerprint, > - or by a prefix byte with the hash algorithm, > - or by a prefix byte with the key version number, > - or by a prefix byte with the length of the fingerprint. This is tricky: a further related question is how OpenPGP = implementations decide what =E2=80=9Ckind=E2=80=9D of fingerprint to = produce, or present to the user, or expect to get, when doing something = with a particular public key. As many people have pointed out, it will = be terrible for user experience if users have to start juggling = =E2=80=9Cnew-style=E2=80=9D and =E2=80=9Cold-style=E2=80=9D fingerprints = for the same public key: e.g., you sent me your pub key and I want to = verify it but your OpenPGP implementation defaulted to the new = fingerprint but mine is giving me an old-style fingerprint to compare = against. A couple possible solutions occur: - Define each pub key scheme as having one and only one corresponding = fingerprint scheme. i.e., all existing/legacy pub key schemes remain = stuck with old SHA1 fingerprints and only new pubkeys generated under a = new pub key scheme will get new-style fingerprints. This would have the = desirable property of ensuring that users never confusingly see two = different legitimate fingerprints for the same public key - but it might = mean that we never get to use new fingerprints with RSA/DSA key pairs = etc, which may be a non-starter. - Add a =E2=80=9Cpreferred fingerprint scheme=E2=80=9D field of some = kind to the self-signed cert that public keys are created with, so it = becomes a property like E-mail address etc. Benefit: users still only = ever see one fingerprint for a given public key, SHA1 for old public = keys or SHA256 (or whatever) for newly-created public keys, even if the = new public key uses an =E2=80=9Cold=E2=80=9D pub key scheme like = RSA/DSA. Drawbacks: implementation complexity; users need to regenerate = (or at least re-self-sign) their keys if they want to get a new-style = fingerprint for their pre-existing public keys. >=20 >> 2. What exactly should the OpenPGP =E2=80=9Capplication=E2=80=9D = fingerprint with that scheme? >>=20 >> To clarify, I propose to define a =E2=80=9Cfingerprint scheme=E2=80=9D = as an algorithm >> that takes a raw octet string and produces an ASCII string of some >=20 > You describe how a fingerprint is presented to the user. This has = been > out of scope for OpenPGP. Implementations have settled for a de-facto > standard outside of the protocol. I think we should keep it this way > and at best give only a suggestion for a human readable format. >=20 > Humans are bad at comparing fingerprints; this should in general be = left > to the software and additional protocols to establish a connection > between an identity and a key/fingerprint. Although it might be good enough to rely in practice on =E2=80=9Cde = facto=E2=80=9D standards for fingerprint presentation, it would suck if = two users with different OpenPGP implementations had no way at all of = comparing/verifying fingerprints because one uses presentation X and the = other uses presentation Y and there=E2=80=99s no common ground. = Wouldn=E2=80=99t it at least be worth recommending at least one = =E2=80=9Ccommon=E2=80=9D fingerprint presentation format be supported = for cross-implementation verifiability, even if individual = implementations might have their own =E2=80=9Cpreferred=E2=80=9D = presentation/verification mechanism for when both users are using the = same implementation? B >=20 >=20 > Shalom-Salam, >=20 > Werner >=20 > --=20 > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >=20 --Apple-Mail=_714D4858-8321-453A-BCF1-3D1F6DAF23A8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDcxNDQ0MTJaMCMGCSqGSIb3DQEJBDEWBBRxmBmbskyGISNcMLZN875WNfmsejCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEABfADMAELBvfS0152TtZbzB05wYVsJPQjfkIWsiQmcZk54J+DocGd9GK6Mj4eKYGd yL60CZRT99GPh5EGbU+ow6rlmZ1cG4jdJ0jhEcRkg4KEVzu7qFhtStRYdJdK0l2bz8DHArufOc9z d6qYg8YTvm2bQ60X6ZviS6pEyolYVvjbGNeGYOEqnDUAD8cnjSoibWrnmL4JkQrnJFP9NQwZkaOZ TVpjYcse83wy0TZRC9CMjcMFRsJBXiEM5bY4aMWVMlDoApkoUsOpE7oAgddCzJv0W8mTl3aHrX8Z MF/YNoSD65kcI+74GeAxJ25ulBxKNrGj1XJ2hDyMm1ON/oVWwgAAAAAAAA== --Apple-Mail=_714D4858-8321-453A-BCF1-3D1F6DAF23A8-- From nobody Thu Apr 7 08:09:46 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D74A12D51A for ; Thu, 7 Apr 2016 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2B35M_MmLBs for ; Thu, 7 Apr 2016 08:09:40 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 76A1A12D9A4 for ; Thu, 7 Apr 2016 07:56:35 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id i4so31692738qkc.3 for ; Thu, 07 Apr 2016 07:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pAQzivj/LzJyBOr9Ajk5xm0STk+/qPzYfTdnbG9BPt8=; b=giMXrRDQr9QOjmwmUKPvqIkhLN4NzpABtNFUsZCi7FYT0nm+hRW8ZgisF4AJJkkJZC YBBxvsLHiHJXoNU+gc9d7vmlW4vyWsbZpFtkNVLf0zMHZMX4BQiOVMLttDIcZjYpU1zV eorrRJRKlTQP/7Fr3ntecZgfrEFcEp8loR1Va9+yLhK4/oq56EyaL0Gvsyj6LGyOvDHG O3yxWvkvDSE5bi9J0FqdA3abYOA06bjnmcdE7q2D6a8FenjzOgoFvTRH3NFCpoMF4Xoq CgBerMXKy4NeKlGtxqKi9fOP623mmlTZKIchBwOwhv2/mijsZZUGikVILydrvCUkgpbe o2XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pAQzivj/LzJyBOr9Ajk5xm0STk+/qPzYfTdnbG9BPt8=; b=AVHUFjXxKZdlKPuGTJ4yUfHpw9igNrEeGJFV5vkXicMIz2JuETQ98efkg9ZUBURngV BhcD0cLCt/5Gg2dMOkwB7ChxHPvWu/HJ0+jWa9wWmhgaEUHjOmicWnhKrOBgHNkfS9rc RojhwI050pyNphwCt494H2IYX2QQN4hB1bxYx/s3dKgAPLGHe7+uDsGUlVuF7n2AfUYo FZ4kIpYeZKs6KWrP2waoIEGYsdyUIqAPwe5UoydZWGmxD31W6GZbxV7Fl1/8Qs1nPV8v sMJYl8z1tNE5fAA/o61cHf/uQHnPKOtxnSBWKCY4ebvGam+U3CLdrjlla3yDX0B2pMMW QA5A== X-Gm-Message-State: AD7BkJJ4lWtQxX0r9RRITum+BpUCOOyNKm8df5dapXXahVVbtRKnUM/MzbWqR9OCTVo7Iw== X-Received: by 10.55.77.4 with SMTP id a4mr4284572qkb.57.1460040994564; Thu, 07 Apr 2016 07:56:34 -0700 (PDT) Received: from [192.168.1.194] ([201.177.50.160]) by smtp.gmail.com with ESMTPSA id y129sm3548635qka.33.2016.04.07.07.56.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 07:56:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3CAAC1A2-8CDE-4728-92B0-85563B3AE783"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> Date: Thu, 7 Apr 2016 11:55:36 -0300 Message-Id: References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:09:45 -0000 --Apple-Mail=_3CAAC1A2-8CDE-4728-92B0-85563B3AE783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 6, 2016, at 7:39 PM, Jon Callas wrote: >=20 > I don't get it. What problem are you trying to solve. Along with the = previous note -- the fingerprint is in fact merely a hash of the key. = It's a handle you can use in a database to identify the key with a fixed = string. That's it. The problem is that one of the most common uses of fingerprints in = practice is to verify consistency. A lot of the people I meet at conferences who use PGP at all tend to put = their PGP key fingerprint on their business card. People also put their = PGP key fingerprints on their websites, etc. Given the general = unusability of the =E2=80=9Cweb-of-trust=E2=80=9D model as originally = envisioned and the lack of any better form of effective PKI in the PGP = ecosystem, this casual fingerprint verification often tends to be =E2=80=9C= the best we can do=E2=80=9D in terms of actually ensuring that you have = the key you think you have. But when eyeball-verifying a fingerprint, how many people really = look/compare beyond the first 10 digits or so? Whether mentally or = verbally, we=E2=80=99re all tempted just to say, =E2=80=9Coh yeah, = that=E2=80=99s the fingerprint that starts with =E2=80=A6=E2=80=9D and = assume we=E2=80=99re done. Which leaves a huge attack vulnerability, at least in principle = (although I don=E2=80=99t know if it=E2=80=99s actually happened in = practice). Someone who wants to pass themselves off as me can simply = spend a bit of time mining for a new PGP key whose fingerprint matches = mine, or yours, in the first 10 digits or so, and perhaps the last few = as well. They post their key with my E-mail address on one or more PGP = key servers, and people download it and assume it=E2=80=99s my key = because it =E2=80=9Clooks like=E2=80=9D the fingerprint on my business = card or web site in the first and/or last digits, the only ones they = actually look at. They might not be able to fool everyone that way, but = still it seems like a pretty serious concern. The whole idea of providing some form of =E2=80=9Cmining-resistance=E2=80=9D= in a fingerprint scheme is to enable the key-owner to invest some = effort at key-creation time, to ensure that any attacker who wants to = try to mine for a key with a similar-looking fingerprint will have to = invest a *lot* more time and effort, not just a little. Does this make sense? B >=20 > Jon >=20 --Apple-Mail=_3CAAC1A2-8CDE-4728-92B0-85563B3AE783 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDcxNDU1MzZaMCMGCSqGSIb3DQEJBDEWBBT6xhvfdbKiYlP6I/aefG5iJnubQTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAaiPsvHzhHndD6B13bu9GaPSDV01rM1WRZdoUUeWstTlakjIU7axovyMx1zG7Hyhb 7co1Qx3/3BGz6H4l+lXoM2xqkcLfbUX4gfLbCnca0/D8Ow0nVBY+AZnc6Xm2w69QzI5xvtoveOuw 2hv2LEdGxg51bM2P2IakK5Qm/82bCihctoIWClqGw0/lo47IrHqse3EkHL/vTsZbFXx57VDszuz3 Ry7IqtfzmHX+413bvacYH2qsX5rehyTZx4lrq1cDBmXK2zYfaLynpUb0sPgON0P3jZNjJbiv7Ogt pumqNSbD70oyMRRUG12W2G6MTn07nDKX5vINTlOLjkmnn+N5CwAAAAAAAA== --Apple-Mail=_3CAAC1A2-8CDE-4728-92B0-85563B3AE783-- From nobody Thu Apr 7 08:28:34 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F41F12D543 for ; Thu, 7 Apr 2016 08:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVUqmW2rF7NG for ; Thu, 7 Apr 2016 08:28: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 3B4FB12D5BF for ; Thu, 7 Apr 2016 08:20:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aoBjG-0000Yq-Mz for ; Thu, 07 Apr 2016 17:20:18 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aoBes-0000Ue-6W; Thu, 07 Apr 2016 17:15:46 +0200 From: Werner Koch To: Bryan Ford References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <87egahvs5i.fsf@wheatstone.g10code.de> <333ABB52-E84C-4039-80AE-01ABE65A91D7@gmail.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Bryan Ford , openpgp@ietf.org Date: Thu, 07 Apr 2016 17:15:46 +0200 In-Reply-To: <333ABB52-E84C-4039-80AE-01ABE65A91D7@gmail.com> (Bryan Ford's message of "Thu, 7 Apr 2016 11:44:11 -0300") Message-ID: <871t6hsb4t.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:28:32 -0000 On Thu, 7 Apr 2016 16:44, brynosaurus@gmail.com said: > What about Blake2? If OpenPGP will be using Argon2 for password > hashing, then all implementations will need to have a Blake2 I was out of the room for some ninutes while this was discussed yesterday. I did not assume that this will be a MUST algorithm. > This is tricky: a further related question is how OpenPGP > implementations decide what =E2=80=9Ckind=E2=80=9D of fingerprint to prod= uce, or That is easy: a v4 key creates a v4 fingerprint (SHA-1) and for the new fingerprint we will requires a v5 key format. We have a lot of experience with that given that v3 keys used yet another fingerprint > present to the user, or expect to get, when doing something with a > particular public key. As many people have pointed out, it will be > terrible for user experience if users have to start juggling > =E2=80=9Cnew-style=E2=80=9D and =E2=80=9Cold-style=E2=80=9D fingerprints = for the same public key: IIRC, we agreed that there will be only one fingerprint format for a given key. Obviously this means that existing keys can't use the new fingerprint format - which is not a problem at all. > - Define each pub key scheme as having one and only one corresponding > fingerprint scheme. i.e., all existing/legacy pub key schemes remain > stuck with old SHA1 fingerprints and only new pubkeys generated under [..] > might mean that we never get to use new fingerprints with RSA/DSA key > pairs etc, which may be a non-starter. Why should one not be able to create an RSA, DSA, or ECDSA key with the new format? It will take some time until one can switch to the new format so that most user are able to handles this. But this unavoidable in any case. > - Add a =E2=80=9Cpreferred fingerprint scheme=E2=80=9D field of some kind= to the Ah no, this defeats the goal of having a unique fingerprint for one key. > Although it might be good enough to rely in practice on =E2=80=9Cde facto= =E2=80=9D > standards for fingerprint presentation, it would suck if two users It worked well the last 20 years (modulo the need to compare date and size of the v3 keys). > with different OpenPGP implementations had no way at all of > comparing/verifying fingerprints because one uses presentation X and Let them enter the fingerprint into their GUI and the software does the match. Shalom-Salam, Werner --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 7 10:51:02 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043D512D655 for ; Thu, 7 Apr 2016 10:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYminKIQYlSH for ; Thu, 7 Apr 2016 10:50:51 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 36CE812D637 for ; Thu, 7 Apr 2016 10:50:34 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o6so33953453qkc.2 for ; Thu, 07 Apr 2016 10:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9XrFzyaGwzelf79FfnF2+CBnQGKp+oVqpY+Sgky6zn0=; b=F+VXPqIYEsTLOU8KFRS7gwReEHCvj9bivl3fqq98xfQbof6xzors63RUTOc4ZY9vPr YuNgZMxgx0Tv+VGHBQqsg9xu47F4dvPOoUyH4aHvoeuHimMaL5qaRzbgNmIxNQeDSaU9 NZsLM/+oW89Hr0y8WflVHNSWOVfq9VptQtzd8tN+45iZECF/igf4uPdJPdRz+iVkXs64 fzubsIxHitOuV+wFq8GDmoDyG4LiFzK1dmlTsykFrkiHKOfMoiZXgHmrlMidVfIZUIIO ycEpDmmTu7aVQczL2h1cn+qh9xC2CGnP6x3fmqNr4MWlvcVCnfO2Q/BECzNTxEsAbHLF oglQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9XrFzyaGwzelf79FfnF2+CBnQGKp+oVqpY+Sgky6zn0=; b=aSe8INgpQ1c8DRnw+annLDuBpi3kJQypml1xOPwtfb+1x5yoZUfHN5Alddwo0pBLfd VOiRd2e8UaTmuakoe7Z3rwz0f72TP83zf8KeEzuLtce8Jv3c6tJoUEonCZohPGZMu4uq Op2XA08DSTW2yYncdtGjcgB5Iz/U6866ShjwbH2O5Fnp24TqKDcjDIs8uIfFvLhrtZcn tGQFqZcsZsPZ41EJ4rZwiR9GpDLDk1aysdWL8r01vQxVqVGvThV5KJEuVgxvhWx+sOA2 QROO621em7U2dEmku53iKSGUFrRTmah6eBd2SYfIBdb/H1GjutTIhUt/gPHEr4mEMePx SCFA== X-Gm-Message-State: AD7BkJKY5O+8sltv8v2rsdjo4PJoTGoK8pBm4myhQrtTEx61PQLBoV7tdPAqcxspcsP4CA== X-Received: by 10.55.71.135 with SMTP id u129mr5674089qka.26.1460051433406; Thu, 07 Apr 2016 10:50:33 -0700 (PDT) Received: from [172.16.2.17] ([190.111.246.13]) by smtp.gmail.com with ESMTPSA id z64sm3805167qhz.32.2016.04.07.10.50.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 10:50:31 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CA05A3DF-D5C5-4187-B5DD-FF8FEF33786E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <871t6hsb4t.fsf@wheatstone.g10code.de> Date: Thu, 7 Apr 2016 14:50:28 -0300 Message-Id: <6FFB55D1-4767-409B-9396-98689169C56E@gmail.com> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <87egahvs5i.fsf@wheatstone.g10code.de> <333ABB52-E84C-4039-80AE-01ABE65A91D7@gmail.com> <871t6hsb4t.fsf@wheatstone.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:50:54 -0000 --Apple-Mail=_CA05A3DF-D5C5-4187-B5DD-FF8FEF33786E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 7, 2016, at 12:15 PM, Werner Koch wrote: >> This is tricky: a further related question is how OpenPGP >> implementations decide what =E2=80=9Ckind=E2=80=9D of fingerprint to = produce, or >=20 > That is easy: a v4 key creates a v4 fingerprint (SHA-1) and for the = new > fingerprint we will requires a v5 key format. We have a lot of > experience with that given that v3 keys used yet another fingerprint Sounds reasonable; I didn=E2=80=99t know that was the precedent for PGP = but given so it makes sense to stick to it. And I=E2=80=99m coming around to agreeing with the KISS position that = fingerprints should deterministically depend only on the raw key = material. But I=E2=80=99m still interested in hearing any discussion of the idea = of designing the new fingerprint function so that users can (optionally) = get some fingerprint-mining protection, as proposed in my other E-mail. Thanks Bryan --Apple-Mail=_CA05A3DF-D5C5-4187-B5DD-FF8FEF33786E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDcxNzUwMjlaMCMGCSqGSIb3DQEJBDEWBBSMWzTubhEsV5IEMPufysFB09gVXTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAiPah2Clb0tCrwsCAqIAvraJtDRcEKKg+OkxY6ELRxwlYrkm+EHKRkYjY8jZMhC1K 5DJaegTBCslfqNe+aQLGWvP1f9WO6u4ScIxYKdISpC7BRulYxzXV57Ytmeg/b7+VtHMiNS5nCS0X 6FrrN9krOfeHaTskHrG1coGAhQYYjBMZTKjVYTLVDsSgALUv8cWO97azjJUzB447xmVLtpyFC8af OCf9ryHWVY9FT+5+DrkjA841JdxngPOkYgJ031hmVgk5L0o8Q9C1d9UhphLJJJqpsG6QC0HbKkoA 0F9IsyrCpfIOpesL3CzzUJmaIeOEnFCiIWizKnZjVGf1Sn9qLwAAAAAAAA== --Apple-Mail=_CA05A3DF-D5C5-4187-B5DD-FF8FEF33786E-- From nobody Thu Apr 7 12:59:33 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3B512D18B for ; Thu, 7 Apr 2016 12:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRqziZKsKHZ5 for ; Thu, 7 Apr 2016 12:59: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 AA1FB12D17D for ; Thu, 7 Apr 2016 12:59:28 -0700 (PDT) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aoG58-0006Zd-OI; Thu, 07 Apr 2016 15:59:10 -0400 Date: Thu, 7 Apr 2016 12:59:05 -0700 From: Bill Frantz To: Werner Koch X-Priority: 3 In-Reply-To: <87egahvs5i.fsf@wheatstone.g10code.de> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec799a7516b8e5f8b4be5ac856b7bc5ba10f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Archived-At: Cc: openpgp@ietf.org, Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:59:31 -0000 On 4/7/16 at 11:39 PM, wk@gnupg.org (Werner Koch) wrote: >On Wed, 6 Apr 2016 20:15, brynosaurus@gmail.com said: > >>1. What fingerprint scheme(s) should OpenPGP move to going forward? > >A SHA-256 hash of the artificial OpenPGP key packet as we use it right >now. The open question is whether to >- include a creation timestamp, >- a timestamp but fixed to 0 (as Google End-to-End does), >- some other static info data to surely separate that fingerprint from >other protocols fingerprint using the same key (i.e. token based) >- no creation timestamp If we use the string, "PGP Fingerprint", or some such, we get=20 pretty good protection against cross protocol confusion. That=20 string could go in the former timestamp field. >You describe how a fingerprint is presented to the user. This has been >out of scope for OpenPGP. Implementations have settled for a de-facto >standard outside of the protocol. I think we should keep it this way >and at best give only a suggestion for a human readable format. > >Humans are bad at comparing fingerprints; this should in general be left >to the software and additional protocols to establish a connection >between an identity and a key/fingerprint. Bryan discussed the issue of verifying keys via fingerprints=20 from e.g. business cards -- a procedure I have actually=20 performed. And I verified all of the characters in the finger=20 print too. :-) This use case makes a strong case for a standard print format=20 for fingerprints, so a fingerprint from one application can be=20 input to another application for verification (a very good idea=20 Werner), or in true desperation, eyeball verified. I do not see this use case going away because it allows people=20 to eliminate third parties (e.g. web of trust or CAs) and reduce=20 the number of different actors they are depending on for their security. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Re: Hardware Management Modes: | Periwinkle (408)356-8506 | If there's a mode, there's a | 16345=20 Englewood Ave www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos,=20 CA 95032 From nobody Thu Apr 7 16:34:02 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102EC12D535 for ; Thu, 7 Apr 2016 16:34:02 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwpqoXQ0KprC for ; Thu, 7 Apr 2016 16:34:00 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id EE83F12D11E for ; Thu, 7 Apr 2016 16:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 7944D94545C3; Thu, 7 Apr 2016 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCyuBArd1ppx; Thu, 7 Apr 2016 16:33:57 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 02DF794545A3; Thu, 7 Apr 2016 16:33:56 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Thu, 07 Apr 2016 16:33:57 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 07 Apr 2016 16:33:57 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> Date: Thu, 7 Apr 2016 16:33:56 -0700 Message-Id: <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> To: Bryan Ford X-Mailer: Apple Mail (2.3124) Content-Type: multipart/alternative; boundary="Apple-Mail=_D66F3244-0E29-47D4-9B97-A7EC7942E6D6" Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:34:02 -0000 --Apple-Mail=_D66F3244-0E29-47D4-9B97-A7EC7942E6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> If you do #1, then you make it so that you can't use the same key for = multiple purposes. You can't for example use it for aliases and nyms. I = think #1 is a bad idea because it tends to turn the fingerprint into a = tracking identifier and I think that making your crypto be implicitly = tracking-friendly is a bad idea. >=20 > That=E2=80=99s a really good point - I definitely agree with the = desirability of making fingerprints less useful as tracking identifiers. = On the other hand, one might argue that there are other ways to address = this, e.g., by just having separate keys (or subkeys?) representing = nyms. If you *really* want your nyms to be unlinkable to each other it = doesn=E2=80=99t seem avoidable that they=E2=80=99ll need to be based on = separate keys and not just different fingerprints for the same key. Yes, because I can tell you that it's *really* useful to be able to = reuse the key material from alice@example.com for (e.g.) = jobs@example.com or security, or whatever. I've done it a lot over the = years. There's a related trick that people do in X.509 certs -- you keep a = lifetime for your *key* that is longer than the lifetime of the = certificate. There are a lot of reasons for it, and a lot of people do = it, despite it making the PKIX purists hyperventilate.=20 The trick of fingerprint =3D F(key, stuff) has a lot of uses. We can = debate the F, and the stuff, but why toss the principle out? We don't = want to make X.509 certs and S/MIME more useful. >=20 >> So let's talk about #2 and #3 as somewhere on a continuum of saying = that the fingerprint is a computable database identifier that provides = some onewayness from key to fingerprint. >>=20 >> The way OpenPGP presently does it is kinda meh. It achieves the goal = that knowing a fingerprint can find a key, but is merely onto, not = one-to-one. It is, however, the way that it is. >>=20 >> If you change it, you end up with unknown breakage. I also don't see = a *goal*. What problem are you trying to solve? I recognize that = creating a new fingerprint algorithm provides an opportunity, but I have = to ask why. >>=20 >> If you specify extra data to be thrown in, it gives the future more = places to attack fingerprints in clever ways.=20 >=20 > Agreed, and this consideration definitely seems to argue for a strict = 1-to-1 fingerprint-to-key relationship. So here's what I suggest -- either keep the way that at present the = creation time serves as salt, or do something simple like add in an = optional short buffer. Length of the hash is fine. Jon --Apple-Mail=_D66F3244-0E29-47D4-9B97-A7EC7942E6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If you do #1, then you make it so that = you can't use the same key for multiple purposes. You can't for example = use it for aliases and nyms. I think #1 is a bad idea because it tends = to turn the fingerprint into a tracking identifier and I think that = making your crypto be implicitly tracking-friendly is a bad = idea.

That=E2=80=99s a really good point - I definitely agree with = the desirability of making fingerprints less useful as tracking = identifiers.  On the other hand, one might argue that there are = other ways to address this, e.g., by just having separate keys (or = subkeys?) representing nyms.  If you *really* want your nyms to be = unlinkable to each other it doesn=E2=80=99t seem avoidable that = they=E2=80=99ll need to be based on separate keys and not just different = fingerprints for the same = key.

Yes, because I can tell you that it's *really* = useful to be able to reuse the key material from alice@example.com for = (e.g.) jobs@example.com= or security, or whatever. I've done it a lot over the = years.

There's a related trick that = people do in X.509 certs -- you keep a lifetime for your *key* that is = longer than the lifetime of the certificate. There are a lot of reasons = for it, and a lot of people do it, despite it making the PKIX purists = hyperventilate. 

The trick of = fingerprint =3D F(key, stuff) has a lot of uses. We can debate the F, = and the stuff, but why toss the principle out? We don't want to make = X.509 certs and S/MIME more useful.



So let's talk about #2 and #3 as = somewhere on a continuum of saying that the fingerprint is a computable = database identifier that provides some onewayness from key to = fingerprint.

The = way OpenPGP presently does it is kinda meh. It achieves the goal that = knowing a fingerprint can find a key, but is merely onto, not = one-to-one. It is, however, the way that it is.

If you change it, you end up with = unknown breakage. I also don't see a *goal*. What problem are you trying = to solve? I recognize that creating a new fingerprint algorithm provides = an opportunity, but I have to ask why.

If you specify extra data to be thrown = in, it gives the future more places to attack fingerprints in clever = ways. 

Agreed, and this = consideration definitely seems to argue for a strict 1-to-1 = fingerprint-to-key = relationship.

So here's what I suggest -- either keep the way = that at present the creation time serves as salt, or do something simple = like add in an optional short buffer. Length of the hash is = fine.

Jon

= --Apple-Mail=_D66F3244-0E29-47D4-9B97-A7EC7942E6D6-- From nobody Thu Apr 7 16:36:13 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F43712D12E for ; Thu, 7 Apr 2016 16:36:12 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtmvvUGD-LbG for ; Thu, 7 Apr 2016 16:36:11 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 23B4712D11E for ; Thu, 7 Apr 2016 16:36:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id EC3D994546E4; Thu, 7 Apr 2016 16:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTYa0nTgY1kL; Thu, 7 Apr 2016 16:36:09 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id B9B5994546CF; Thu, 7 Apr 2016 16:36:09 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Thu, 07 Apr 2016 16:36:09 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 07 Apr 2016 16:36:09 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: Date: Thu, 7 Apr 2016 16:36:09 -0700 Message-Id: <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> To: Bryan Ford X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:36:12 -0000 > On Apr 7, 2016, at 7:55 AM, Bryan Ford wrote: >=20 > * PGP - S/MIME Signed by an unverified key: 04/07/2016 at 07:55:36 AM >=20 >=20 >> On Apr 6, 2016, at 7:39 PM, Jon Callas wrote: >>=20 >> I don't get it. What problem are you trying to solve. Along with the = previous note -- the fingerprint is in fact merely a hash of the key. = It's a handle you can use in a database to identify the key with a fixed = string. That's it. >=20 > The problem is that one of the most common uses of fingerprints in = practice is to verify consistency. >=20 > A lot of the people I meet at conferences who use PGP at all tend to = put their PGP key fingerprint on their business card. People also put = their PGP key fingerprints on their websites, etc. Given the general = unusability of the =E2=80=9Cweb-of-trust=E2=80=9D model as originally = envisioned and the lack of any better form of effective PKI in the PGP = ecosystem, this casual fingerprint verification often tends to be =E2=80=9C= the best we can do=E2=80=9D in terms of actually ensuring that you have = the key you think you have. >=20 > But when eyeball-verifying a fingerprint, how many people really = look/compare beyond the first 10 digits or so? Whether mentally or = verbally, we=E2=80=99re all tempted just to say, =E2=80=9Coh yeah, = that=E2=80=99s the fingerprint that starts with =E2=80=A6=E2=80=9D and = assume we=E2=80=99re done. >=20 > Which leaves a huge attack vulnerability, at least in principle = (although I don=E2=80=99t know if it=E2=80=99s actually happened in = practice). Someone who wants to pass themselves off as me can simply = spend a bit of time mining for a new PGP key whose fingerprint matches = mine, or yours, in the first 10 digits or so, and perhaps the last few = as well. They post their key with my E-mail address on one or more PGP = key servers, and people download it and assume it=E2=80=99s my key = because it =E2=80=9Clooks like=E2=80=9D the fingerprint on my business = card or web site in the first and/or last digits, the only ones they = actually look at. They might not be able to fool everyone that way, but = still it seems like a pretty serious concern. >=20 > The whole idea of providing some form of =E2=80=9Cmining-resistance=E2=80= =9D in a fingerprint scheme is to enable the key-owner to invest some = effort at key-creation time, to ensure that any attacker who wants to = try to mine for a key with a similar-looking fingerprint will have to = invest a *lot* more time and effort, not just a little. >=20 > Does this make sense? I believe I understand you. You're complexifying key creation for a hypothetical, movie-plot attack. Jon From nobody Thu Apr 7 18:12:18 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423C812D0EE for ; Thu, 7 Apr 2016 18:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i25Bd_Tiun2p for ; Thu, 7 Apr 2016 18:12:14 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d: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 BDC8012D0BE for ; Thu, 7 Apr 2016 18:12:13 -0700 (PDT) Received: by mail-qg0-x229.google.com with SMTP id j35so79123172qge.0 for ; Thu, 07 Apr 2016 18:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=2NWB7WTRCLCFrGLp6eSxlDSEXA9lU9wBWevTQi2Wt58=; b=qhp2WPb64XsA8uYWDrbhceoNlIH0dSxy40O2kkstkftOPpDl9CtpL8bpSHqdQHobt7 IxrB+SQU/soHwu75p8V5/UexyGuYJqB4yR8rvyG4OMFQboVDWuxxPaybNm6K2WxetqNk umybhrLRb6+ELMsDcaOD3JVx+rYl3HvATU9ToOVtm1rjb9EmPAbZtXWWnjviogzYeVod ltwLXIsGwgjlF07rG3c079qecfRXePKm71Vuh6swD2pJ27MVRJl6W09qRUq/iya1Qk5s d/uBk1z8nHuekQpTIMH5Cvr5AgIVTHuJ8Rc/2D/cocj30FJZ8nHTWMJPjPHFzgvvMmT/ n8aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2NWB7WTRCLCFrGLp6eSxlDSEXA9lU9wBWevTQi2Wt58=; b=eGpKsIw/iSYwHAypmnLHV1tJ7hz36f11h+qwalS+aEzZ5l3tOfuXl6IIe4euBpHCHQ 28yX4KS0odb+0Fq7fsFTKYYF499E/Nw+gVcTwJFAQ/mVpuU7F4pQ3IgtFGWE+a/HqG3D XWOpis/Pzv0xxTwWfn6DbTxWpqHVKsxgSAGS+bJC2KGIcfr1xivBbfpBDvXQHi281XWz VJ/UxZ9NUCO3eUVOoxt2EKd3JEzrY6OCLpPdcdFtLIxt/2hJfLkqoL3ES+za+suf35TR T32+7S0zgOlTpfbIIA+ZioMQs9izK+ht+MmiCgJP0WTk2UYWOhtuJ1HZKy4ucEKIOBkw 8U6w== X-Gm-Message-State: AD7BkJK8vb0Zk0ePIlbuV1Y1ZyEg+JKuqoJf+uN5q0tS04IoU7AbvG7o+PriaCozcN2jzQ== X-Received: by 10.140.91.34 with SMTP id y31mr7975771qgd.84.1460077932852; Thu, 07 Apr 2016 18:12:12 -0700 (PDT) Received: from [172.16.2.17] ([190.111.246.13]) by smtp.gmail.com with ESMTPSA id x6sm4596815qka.16.2016.04.07.18.12.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 18:12:10 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AD6E8404-182B-4550-ADE9-DF55684BC164"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> Date: Thu, 7 Apr 2016 22:12:06 -0300 Message-Id: References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:12:16 -0000 --Apple-Mail=_AD6E8404-182B-4550-ADE9-DF55684BC164 Content-Type: multipart/alternative; boundary="Apple-Mail=_9C86FBCD-AB34-4E26-AE9F-A8F035A48757" --Apple-Mail=_9C86FBCD-AB34-4E26-AE9F-A8F035A48757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2016, at 8:36 PM, Jon Callas wrote: >> On Apr 7, 2016, at 7:55 AM, Bryan Ford > wrote: >> The whole idea of providing some form of =E2=80=9Cmining-resistance=E2=80= =9D in a fingerprint scheme is to enable the key-owner to invest some = effort at key-creation time, to ensure that any attacker who wants to = try to mine for a key with a similar-looking fingerprint will have to = invest a *lot* more time and effort, not just a little. >>=20 >> Does this make sense? >=20 > I believe I understand you. >=20 > You're complexifying key creation for a hypothetical, movie-plot = attack. This attitude, that IETF-standardized protocols should not attempt to = address known or foreseeable weaknesses unless there are documented = cases of those specific attacks happening in the wild *right now*, is = one key reason Internet security is in such a horrific state. When = protocol designs only ever attempt to address attacks that have already = been documented in the wild - and calling all other attacks = =E2=80=9Cmovie-plot=E2=80=9D scenarios - by definition you=E2=80=99re = always playing catch-up and attackers will always be ahead. The = pervasiveness of this attitude, while understandable, makes me sad. In the case of fingerprint-mining, we actually do have documented = evidence of that occurring, the most obvious and well-known being = Facebook=E2=80=99s vanity .onion address. The fact that Facebook was = not maliciously attacking anyone else - in effect they were only = =E2=80=9Cattacking=E2=80=9D their own brand-name by mining for a = public-key whose .onion address would look like it - does not change the = fact that their action demonstrated that both the capability and the = incentives exist in the real-world to mine for fingerprints that look = similar to something-or-other. If it so happened that the =E2=80=9Creal=E2= =80=9D Facebook was mounting this attack against its own brand, the next = time it might be a fake Facebook imposter mounting the same attack = against Facebook by creating a similar-looking vanity name and hoping = users will fall for it. The issue is not who or what the = fingerprint-miner is trying to make their mined fingerprint look like; = the issue is that such attacks are clearly practical. Documented fingerprint-mining attacks have occurred in other domains = too: for example, not too long ago I remember that it was found that the = Ripple ledger was vulnerable to =E2=80=9CTransaction ID=E2=80=9D = fingerprint-mining attacks that were actually being exploited, in which = an attacker mined for low-numbered transaction IDs which would cause = their transactions to get processed first and provide arbitrage = opportunities. Obviously the fingerprint-mining was for a fairly = different purpose in this case, but still it=E2=80=99s another = documented example of the same general class of weakness: i.e., an = attacker mining for a hash-based fingerprint that looks kinda like = something that will help him get what he wants in some way. Bryan --Apple-Mail=_9C86FBCD-AB34-4E26-AE9F-A8F035A48757 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 7, 2016, at 8:36 PM, Jon Callas <jon@callas.org> = wrote:
On Apr 7, 2016, at 7:55 AM, = Bryan Ford <brynosaurus@gmail.com> wrote:
The whole = idea of providing some form of =E2=80=9Cmining-resistance=E2=80=9D in a = fingerprint scheme is to enable the key-owner to invest some effort at = key-creation time, to ensure that any attacker who wants to try to mine = for a key with a similar-looking fingerprint will have to invest a *lot* = more time and effort, not just a little.

Does= this make sense?

I believe I understand you.

You're complexifying key creation for a = hypothetical, movie-plot attack.

This = attitude, that IETF-standardized protocols should not attempt to address = known or foreseeable weaknesses unless there are documented cases of = those specific attacks happening in the wild *right now*, is one key = reason Internet security is in such a horrific state.  When = protocol designs only ever attempt to address attacks that have already = been documented in the wild - and calling all other attacks = =E2=80=9Cmovie-plot=E2=80=9D scenarios - by definition you=E2=80=99re = always playing catch-up and attackers will always be ahead.  The = pervasiveness of this attitude, while understandable, makes me sad.

In the case of fingerprint-mining, we actually do have = documented evidence of that occurring, the most obvious and well-known = being Facebook=E2=80=99s vanity .onion address.  The fact that = Facebook was not maliciously attacking anyone else - in effect they were = only =E2=80=9Cattacking=E2=80=9D their own brand-name by mining for a = public-key whose .onion address would look like it - does not change the = fact that their action demonstrated that both the capability and the = incentives exist in the real-world to mine for fingerprints that look = similar to something-or-other.  If it so happened that the = =E2=80=9Creal=E2=80=9D Facebook was mounting this attack against its own = brand, the next time it might be a fake Facebook imposter mounting the = same attack against Facebook by creating a similar-looking vanity name = and hoping users will fall for it.  The issue is not who or what = the fingerprint-miner is trying to make their mined fingerprint look = like; the issue is that such attacks are clearly = practical.

Documented fingerprint-mining attacks have occurred in other = domains too: for example, not too long ago I remember that it was found = that the Ripple ledger was vulnerable to =E2=80=9CTransaction ID=E2=80=9D = fingerprint-mining attacks that were actually being exploited, in which = an attacker mined for low-numbered transaction IDs which would cause = their transactions to get processed first and provide arbitrage = opportunities.  Obviously the fingerprint-mining was for a fairly = different purpose in this case, but still it=E2=80=99s another = documented example of the same general class of weakness: i.e., an = attacker mining for a hash-based fingerprint that looks kinda like = something that will help him get what he wants in some way.

Bryan

= --Apple-Mail=_9C86FBCD-AB34-4E26-AE9F-A8F035A48757-- --Apple-Mail=_AD6E8404-182B-4550-ADE9-DF55684BC164 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDgwMTEyMDZaMCMGCSqGSIb3DQEJBDEWBBQgCgA7Q3Yapm/XW9ND5XDvUQOIJjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAVeHnKZgHesTYAAsEkyfa53zpLVzpMUfOJ+rr95ZdTVzh6YEEFkk0nxHEupEaKQ0G UF4jmHFsJ8ndgaxyuqanwYsLVNee92R0f3a2UGcmuzBtjvx1JeJG3qayG7PwQU9tE2YpR5lJfjtR J0OpWbXpc7F19EpSPwe8JyihgtNLYHAtQF9Zf6FZwNk4EkKjyPWePYr5nNgw9uGwoVL+HKns8bso GF9ptpLfrcfwkYuyyOihRn5kAkkipjyEXUoZszhKRclmyF9QRMUQC3mwrrg/NA4JhcXgLWFQ+VM5 s21QFwX6p5y7XeNogF8vMHagiflxroCQWl+k9t4W/bIp5XDKrAAAAAAAAA== --Apple-Mail=_AD6E8404-182B-4550-ADE9-DF55684BC164-- From nobody Thu Apr 7 18:28:39 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DD712D5CD for ; Thu, 7 Apr 2016 18:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt6RWxWlu1gg for ; Thu, 7 Apr 2016 18:28:35 -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 5E5D012D1CF for ; Thu, 7 Apr 2016 18:28:35 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aoLDt-00069I-Ab for openpgp@ietf.org; Thu, 07 Apr 2016 19:28:33 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1aoLDr-0003bR-5t for openpgp@ietf.org; Thu, 07 Apr 2016 19:28:33 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u381RxLo014334 for ; Thu, 7 Apr 2016 19:27:59 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u381RxEI014333; Thu, 7 Apr 2016 19:27:59 -0600 Date: Thu, 7 Apr 2016 19:27:59 -0600 Message-Id: <201604080127.u381RxEI014333@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: openpgp@ietf.org In-reply-to: Yourmessage <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> X-XM-AID: U2FsdGVkX1/Gz0uaEaZq9AJSaB6yUQXi X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;openpgp@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 1763 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.2 (0.2%), b_tie_ro: 3.0 (0.2%), parse: 0.91 (0.1%), extract_message_metadata: 25 (1.4%), get_uri_detail_list: 2.8 (0.2%), tests_pri_-1000: 7 (0.4%), tests_pri_-950: 1.96 (0.1%), tests_pri_-900: 1.36 (0.1%), tests_pri_-400: 30 (1.7%), check_bayes: 28 (1.6%), b_tokenize: 9 (0.5%), b_tok_get_all: 7 (0.4%), b_comp_prob: 4.3 (0.2%), b_tok_touch_all: 2.7 (0.2%), b_finish: 1.12 (0.1%), tests_pri_0: 1652 (93.7%), check_dkim_signature: 1.09 (0.1%), check_dkim_adsp: 306 (17.4%), tests_pri_500: 10 (0.6%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:28:38 -0000 > Date: Thu, 7 Apr 2016 16:36:09 -0700 > > On Apr 7, 2016, at 7:55 AM, Bryan Ford wrote: > > > > * PGP - S/MIME Signed by an unverified key: 04/07/2016 at 07:55:36 AM > > > > > >> On Apr 6, 2016, at 7:39 PM, Jon Callas wrote: > >> > >> I don't get it. What problem are you trying to solve. Along with the previous note -- the fingerprint is in fact merely a hash of the key. It's a handle you can use in a database to identify the key with a fixed string. That's it. > > > > The problem is that one of the most common uses of fingerprints in practice is to verify consistency. > > > > A lot of the people I meet at conferences who use PGP at all tend to put their PGP key fingerprint on their business card. People also put their PGP key fingerprints on their websites, etc. Given the general unusability of the “web-of-trust” model as originally envisioned and the lack of any better form of effective PKI in the PGP ecosystem, this casual fingerprint verification often tends to be “the best we can do” in terms of actually ensuring that you have the key you think you have. > > > > But when eyeball-verifying a fingerprint, how many people really look/compare beyond the first 10 digits or so? Whether mentally or verbally, we’re all tempted just to say, “oh yeah, that’s the fingerprint that starts with …” and assume we’re done. > > > > Which leaves a huge attack vulnerability, at least in principle (although I don’t know if it’s actually happened in practice). Someone who wants to pass themselves off as me can simply spend a bit of time mining for a new PGP key whose fingerprint matches mine, or yours, in the first 10 digits or so, and perhaps the last few as well. They post their key with my E-mail address on one or more PGP key servers, and people download it and assume it’s my key because it “looks like” the fingerprint on my business card or web site in the first and/or last digits, the only ones they actually look at. They might not be able to fool everyone that way, but still it seems like a pretty serious concern. > > > > The whole idea of providing some form of “mining-resistance” in a fingerprint scheme is to enable the key-owner to invest some effort at key-creation time, to ensure that any attacker who wants to try to mine for a key with a similar-looking fingerprint will have to invest a *lot* more time and effort, not just a little. > > > > Does this make sense? > I believe I understand you. > You're complexifying key creation for a hypothetical, movie-plot attack. > Jon Millions of people every year are victims of fake business card attacks. I read that somewhere. Hilarie From nobody Thu Apr 7 23:30:26 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C238512D1DA for ; Thu, 7 Apr 2016 23:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwLIr1v5abuQ for ; Thu, 7 Apr 2016 23:30:20 -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 B34B612D5FE for ; Thu, 7 Apr 2016 23:30:15 -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=1460097017; x=1491633017; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ibcVaNJjVXbSw9nrYQEq0XH4o0NHaIpJFk6U+ICJllI=; b=3UlTZNqdk9BSf8BhPYYrDem7/03yWWmDM/j1Wzah/XXj5OAfGHZ/Vhj5 dBYcBWZ8NlXItsouuI44vC4Og16vJ22gO11l3SeuQNqIfYjKvX6IuuoaR eVNi6zFCyxDXJ3CKMLfAzPJ+O6GCZLizhjpqUzWVawYt8thZl7CAM0EDy RD9nghj/YwrdoqYIu5bsA8aQeklbmkQWhOVvBKry6kMUEMSU82914Y/4C shPTANd35dNS08FW1m0wiI7+0lVm4a4WbQeFl1oOl3RLhpDSfss+sU5ca CupUWwdDFH+qShpo1sRjYyROKFAi0Vr9DmuJijSF1r0Y14a89E6GMB65w w==; X-IronPort-AV: E=Sophos;i="5.24,449,1454929200"; d="scan'208";a="78993033" 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/AES256-SHA; 08 Apr 2016 18:30:10 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Fri, 8 Apr 2016 18:30:09 +1200 From: Peter Gutmann To: Bryan Ford , Jon Callas Thread-Topic: [openpgp] Mining protection in fingerprint schemes Thread-Index: AQHRkD712bG2iqLU6EOL6HNGn5mjH598wM8AgAEQngCAAc4v0w== Date: Fri, 8 Apr 2016 06:30:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.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: [10.6.3.3] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 06:30:25 -0000 Bryan Ford writes:=0A= =0A= >Someone who wants to pass themselves off as me can simply spend a bit of t= ime=0A= >mining for a new PGP key whose fingerprint matches mine, or yours, in the= =0A= >first 10 digits or so, and perhaps the last few as well. =0A= =0A= We already have good data on that via SSH's fuzzy fingerprints, with tools = to=0A= generate and exploit them having been around for some years. They're quite= =0A= effective.=0A= =0A= >The whole idea of providing some form of =93mining-resistance=94 in a fing= erprint=0A= >scheme is to enable the key-owner to invest some effort at key-creation ti= me,=0A= >to ensure that any attacker who wants to try to mine for a key with a simi= lar-=0A= >looking fingerprint will have to invest a *lot* more time and effort, not = just=0A= >a little.=0A= =0A= I'm not sure if this is worth the effort, see "Do Users Verify SSH Keys?",= =0A= https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf. The= =0A= solution isn't to try and patch up something that inherently doesn't work= =0A= (look at browser PKI for a twenty-year, and still running, example of tryin= g=0A= to do that) but to look for alternative approaches to dealing with the=0A= problem.=0A= =0A= Peter.= From nobody Fri Apr 8 01:21:03 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044B412D50B for ; Fri, 8 Apr 2016 01:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hC7ifJEJ0IR for ; Fri, 8 Apr 2016 01:21:00 -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 3D7F512D17E for ; Fri, 8 Apr 2016 01:21:00 -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=1460103661; x=1491639661; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dFMz09hY25NWchaxr2s/gG1ETLpR1Cv14dqEdaTCV8E=; b=YrVAo8MOSYA4wPhNCqCtpgXWBvhvwragDVMAGvW2q5VbGn1e50n0DfjR ISJYNuU+/lkWkrXAjc/RhuFWLzmaL4DoBc4xGWuhUWr6udH7DdtX4iPck 5GIDhDk2cwQ0SjoZUhcD6mChf2Z7XSabFBWyQFNtSBeuD1YykqjVKq58s HlU9p+EBUi1cFaJeig8aKYa4tHYwmHixNWp7eJAqZ/e0LT4lb4yigmB5r J8ByByy1MKKZmJlQm9ijUmMcL4IbluM+oWJbwGOLEeOGmQk6IqE8luV0i 4nYkzQm/o0J7GYImokGj31QiU+lxSlEX4o80nxeWGsRVfNRn+e93N3rsN g==; X-IronPort-AV: E=Sophos;i="5.24,449,1454929200"; d="scan'208";a="79001563" 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/AES256-SHA; 08 Apr 2016 20:20:59 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Fri, 8 Apr 2016 20:20:58 +1200 From: Peter Gutmann To: Bryan Ford , Jon Callas Thread-Topic: [openpgp] Mining protection in fingerprint schemes Thread-Index: AQHRkD712bG2iqLU6EOL6HNGn5mjH598wM8AgAEQngCAAJFwgIAAGs8AgAFAvVg= Date: Fri, 8 Apr 2016 08:20:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C46DF3@uxcn10-5.UoA.auckland.ac.nz> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.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: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:21:03 -0000 Bryan Ford writes:=0A= =0A= >This attitude, that IETF-standardized protocols should not attempt to addr= ess=0A= >known or foreseeable weaknesses unless there are documented cases of those= =0A= >specific attacks happening in the wild *right now*, is one key reason=0A= >Internet security is in such a horrific state.=0A= =0A= Or it's the exact opposite, every Internet protocol is expected to defend= =0A= against every theoretically imaginable scenario, which means they have to= =0A= defend against literally [0] everything.=0A= =0A= Since no protocol can defend against everything, what happens in practice i= s=0A= that the most vociferous people involved in its design select a few things= =0A= they care about (the NSA, the mind control satellites, quantum cryptanalysi= s,=0A= and the lizard people) and defend against that, and the fact that a phished= =0A= credit card and a commercial CA who'll sell you any cert you ask for can br= ing=0A= down the whole house of cards is ignored.=0A= =0A= So you need some means of deciding what's worth defending against. "Is thi= s=0A= practical" and "would anyone ever bother doing this" are two reasonable=0A= criteria for estimating what's practical.=0A= =0A= Peter.=0A= =0A= [0] And when I say literally I mean figuratively.= From nobody Fri Apr 8 01:45:46 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6B112D114 for ; Fri, 8 Apr 2016 01:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhtfAn-naSS0 for ; Fri, 8 Apr 2016 01:45:43 -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 A694A12D579 for ; Fri, 8 Apr 2016 01:45:43 -0700 (PDT) Received: from localhost.localdomain (ip72-219-200-232.dc.dc.cox.net [72.219.200.232]) (Authenticated sender: rjh-sixdemonbag) by shards.monkeyblade.net (Postfix) with ESMTPSA id 5C1145AE298 for ; Fri, 8 Apr 2016 01:45:43 -0700 (PDT) To: openpgp@ietf.org References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46DF3@uxcn10-5.UoA.auckland.ac.nz> From: "Robert J. Hansen" X-Enigmail-Draft-Status: N1110 Message-ID: <57076FB5.9060901@sixdemonbag.org> Date: Fri, 8 Apr 2016 04:45:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C46DF3@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=utf-8 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]); Fri, 08 Apr 2016 01:45:43 -0700 (PDT) Archived-At: Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:45:45 -0000 > Or it's the exact opposite, every Internet protocol is expected to > defend against every theoretically imaginable scenario, which means > they have to defend against literally [0] everything. There are three basic states a defender can be in: "of course I'm not being surveilled", "maybe I'm being surveilled", and "of course I'm being surveilled". You want people to stay in the first category at all costs: they speak more freely and with fewer safeguards. You want to keep people out of the latter category at all costs: they speak only what's strictly necessary and use extreme countermeasures. This leads to the attacker's first rule: don't be seen. Bryan's idea violates this. Okay, so you forge a collision on some of the digits... but you have absolutely no idea which digits the defender will check. Or, for that matter, if three days later the defender will look at the business card and say "hey, that's not right". Or... etc. This is such a high-visibility attack, with such a risk of putting a defender into an aware and alert posture, that I have trouble imagining a halfway competent attacker who would ever want to use this. It's a complete roll of the dice, with extreme consequences for failure. From nobody Fri Apr 8 11:32:39 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409C512D5A6 for ; Fri, 8 Apr 2016 11:32:37 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp09CWQO7X7j for ; Fri, 8 Apr 2016 11:32:35 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0EE12D59D for ; Fri, 8 Apr 2016 11:32:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id DB8DE946C698; Fri, 8 Apr 2016 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuluegEmTHtW; Fri, 8 Apr 2016 11:32:33 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id D6778946C67C; Fri, 8 Apr 2016 11:32:32 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 08 Apr 2016 11:32:33 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 08 Apr 2016 11:32:33 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: Date: Fri, 8 Apr 2016 11:32:32 -0700 Message-Id: <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> To: Bryan Ford X-Mailer: Apple Mail (2.3124) Content-Type: multipart/alternative; boundary="Apple-Mail=_24807E06-8D49-4CE8-983C-EE03A1C272B4" Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:32:37 -0000 --Apple-Mail=_24807E06-8D49-4CE8-983C-EE03A1C272B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2016, at 6:12 PM, Bryan Ford wrote: >=20 > * PGP - S/MIME Signed by an unverified key: 04/07/2016 at 06:12:06 PM >=20 >> On Apr 7, 2016, at 8:36 PM, Jon Callas > wrote: >>> On Apr 7, 2016, at 7:55 AM, Bryan Ford > wrote: >>> The whole idea of providing some form of =E2=80=9Cmining-resistance=E2= =80=9D in a fingerprint scheme is to enable the key-owner to invest some = effort at key-creation time, to ensure that any attacker who wants to = try to mine for a key with a similar-looking fingerprint will have to = invest a *lot* more time and effort, not just a little. >>>=20 >>> Does this make sense? >>=20 >> I believe I understand you. >>=20 >> You're complexifying key creation for a hypothetical, movie-plot = attack. >=20 > This attitude, that IETF-standardized protocols should not attempt to = address known or foreseeable weaknesses unless there are documented = cases of those specific attacks happening in the wild *right now*, is = one key reason Internet security is in such a horrific state. When = protocol designs only ever attempt to address attacks that have already = been documented in the wild - and calling all other attacks = =E2=80=9Cmovie-plot=E2=80=9D scenarios - by definition you=E2=80=99re = always playing catch-up and attackers will always be ahead. The = pervasiveness of this attitude, while understandable, makes me sad. The first rule of security is that you can't protect against all = threats. This is why you do things like threat modeling. I'm really sorry you're sad, but you said "although I don=E2=80=99t know = if it=E2=80=99s actually happened in practice" -- which means that it's = a hypothetical attack. But now, below, you're saying it's not. Look, if you were in error and = now know documented cases, when you didn't yesterday, that's cool. We = can always revise. >=20 > In the case of fingerprint-mining, we actually do have documented = evidence of that occurring, the most obvious and well-known being = Facebook=E2=80=99s vanity .onion address. The fact that Facebook was = not maliciously attacking anyone else - in effect they were only = =E2=80=9Cattacking=E2=80=9D their own brand-name by mining for a = public-key whose .onion address would look like it - does not change the = fact that their action demonstrated that both the capability and the = incentives exist in the real-world to mine for fingerprints that look = similar to something-or-other. If it so happened that the =E2=80=9Creal=E2= =80=9D Facebook was mounting this attack against its own brand, the next = time it might be a fake Facebook imposter mounting the same attack = against Facebook by creating a similar-looking vanity name and hoping = users will fall for it. The issue is not who or what the = fingerprint-miner is trying to make their mined fingerprint look like; = the issue is that such attacks are clearly practical. >=20 > Documented fingerprint-mining attacks have occurred in other domains = too: for example, not too long ago I remember that it was found that the = Ripple ledger was vulnerable to =E2=80=9CTransaction ID=E2=80=9D = fingerprint-mining attacks that were actually being exploited, in which = an attacker mined for low-numbered transaction IDs which would cause = their transactions to get processed first and provide arbitrage = opportunities. Obviously the fingerprint-mining was for a fairly = different purpose in this case, but still it=E2=80=99s another = documented example of the same general class of weakness: i.e., an = attacker mining for a hash-based fingerprint that looks kinda like = something that will help him get what he wants in some way. Let me go on a small rant of my own. There is a problem in OpenPGP that it is notoriously too hard to use.=20 I use OpenPGP through a PGP Universal server, but I also use S/MIME. = S/MIME is in my mailer darned easy to use! Heck, your email itself was = signed with S/MIME, not OpenPGP. If you make key creation harder, people will create fewer keys. If you make database lookup from fingerprint to key harder (or more = costly) that makes it harder and more costly. What's the *benefit* we derive from this added complexity and time?=20 Moreover, can this problem be solved in a higher-level system? We need to have a quick way to turn a cryptographic key into a fixed = lookup (database key). The naive solution is a hash of that key, with or = without something else. If we turn the "fingerprint" into something complex, then we need to = have a new thing that does what the old fingerprint does -- a quick = transformation of key into lookup. What should that be? Let me give a proposal of a generic scheme: One of the ideas we had a long time ago was that the "fingerprint" = actually has two fields in it. A tag and a value. I'm still fond myself = of the fingerprint that is=20 : but I'm not wedded to the syntax. I like the idea; I don't care about = the syntax. If that gets adopted, then we *could* have a high-compute fingerprint = and encourage people to put them on their business cards. Does that help? Jon --Apple-Mail=_24807E06-8D49-4CE8-983C-EE03A1C272B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 7, 2016, at 6:12 PM, Bryan Ford <brynosaurus@gmail.com> wrote:

* PGP - S/MIME Signed by an unverified key: 04/07/2016 at 06:12:06 PM

On Apr 7, 2016, at 8:36 PM, Jon Callas <jon@callas.org> = wrote:
On Apr 7, 2016, at 7:55 AM, = Bryan Ford <brynosaurus@gmail.com> wrote:
The whole = idea of providing some form of =E2=80=9Cmining-resistance=E2=80=9D in a = fingerprint scheme is to enable the key-owner to invest some effort at = key-creation time, to ensure that any attacker who wants to try to mine = for a key with a similar-looking fingerprint will have to invest a *lot* = more time and effort, not just a little.

Does= this make sense?

I believe I understand you.

You're complexifying key creation for a = hypothetical, movie-plot attack.

This attitude, that IETF-standardized protocols = should not attempt to address known or foreseeable weaknesses unless = there are documented cases of those specific attacks happening in the = wild *right now*, is one key reason Internet security is in such a = horrific state.  When protocol designs only ever attempt to address = attacks that have already been documented in the wild - and calling all = other attacks =E2=80=9Cmovie-plot=E2=80=9D scenarios - by definition = you=E2=80=99re always playing catch-up and attackers will always be = ahead.  The pervasiveness of this attitude, while understandable, = makes me sad.

The first rule of security is that you can't = protect against all threats. This is why you do things like threat = modeling.

I'm really sorry you're = sad, but you said "although I don=E2=80=99t know if it=E2=80=99s actually = happened in practice" -- which means that it's a hypothetical = attack.

But now, below, you're saying it's not. Look, = if you were in error and now know documented cases, when you didn't = yesterday, that's cool. We can always revise.



In the = case of fingerprint-mining, we actually do have documented evidence of = that occurring, the most obvious and well-known being Facebook=E2=80=99s = vanity .onion address.  The fact that Facebook was not maliciously = attacking anyone else - in effect they were only =E2=80=9Cattacking=E2=80=9D= their own brand-name by mining for a public-key whose .onion address = would look like it - does not change the fact that their action = demonstrated that both the capability and the incentives exist in the = real-world to mine for fingerprints that look similar to = something-or-other.  If it so happened that the =E2=80=9Creal=E2=80=9D= Facebook was mounting this attack against its own brand, the next time = it might be a fake Facebook imposter mounting the same attack against = Facebook by creating a similar-looking vanity name and hoping users will = fall for it.  The issue is not who or what the fingerprint-miner is = trying to make their mined fingerprint look like; the issue is that such = attacks are clearly practical.

Documented fingerprint-mining attacks = have occurred in other domains too: for example, not too long ago I = remember that it was found that the Ripple ledger was vulnerable to = =E2=80=9CTransaction ID=E2=80=9D fingerprint-mining attacks that were = actually being exploited, in which an attacker mined for low-numbered = transaction IDs which would cause their transactions to get processed = first and provide arbitrage opportunities.  Obviously the = fingerprint-mining was for a fairly different purpose in this case, but = still it=E2=80=99s another documented example of the same general class = of weakness: i.e., an attacker mining for a hash-based fingerprint that = looks kinda like something that will help him get what he wants in some = way.

Let me go on a small rant of my own.

There is a problem in OpenPGP that it is = notoriously too hard to use. 

I = use OpenPGP through a PGP Universal server, but I also use S/MIME. = S/MIME is in my mailer darned easy to use! Heck, your email itself was = signed with S/MIME, not OpenPGP.

If = you make key creation harder, people will create fewer = keys.

If you make database lookup = from fingerprint to key harder (or more costly) that makes it harder and = more costly.

What's the *benefit* we = derive from this added complexity and time? 

Moreover, can this problem be solved in a = higher-level system?

We need to have = a quick way to turn a cryptographic key into a fixed lookup (database = key). The naive solution is a hash of that key, with or without = something else.

If we turn the = "fingerprint" into something complex, then we need to have a new thing = that does what the old fingerprint does -- a quick transformation of key = into lookup. What should that be?

Let = me give a proposal of a generic scheme:

One of the ideas we had a long time ago was that = the "fingerprint" actually has two fields in it. A tag and a value. I'm = still fond myself of the fingerprint that is 

<algorithm-id>:<algorithm-value>

but I'm not wedded to the syntax. I like = the idea; I don't care about the syntax.

If that gets adopted, then we *could* have a = high-compute fingerprint and encourage people to put them on their = business cards.

Does that = help?

Jon

= --Apple-Mail=_24807E06-8D49-4CE8-983C-EE03A1C272B4-- From nobody Fri Apr 8 14:59:09 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B5D12D91B for ; Fri, 8 Apr 2016 14:59:08 -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, SPF_FAIL=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFuxtNtJasJ4 for ; Fri, 8 Apr 2016 14:59:06 -0700 (PDT) Received: from castro.crustytoothpaste.net (sandals-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3f1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AFE12D624 for ; Fri, 8 Apr 2016 14:51:29 -0700 (PDT) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:6680:99ff:fe4f:73a0]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id 4A576280A0 for ; Fri, 8 Apr 2016 21:50:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1460152257; bh=0wp8BlutDLeCpntxZQKvGOVGXDoecAIf+bV1OgRDwek=; h=Date:From:To:Subject:References:In-Reply-To:From; b=WQQG5WkPL8tEHpVrOECLIAP2HxgVlA4UC6bnzfdu7DLd2pOJqg9WgBPWnvlWNiogo lAmCxoWgWyHEXA5L9CTO+5wA0GV6f+wKqf+/sFf6zcDW+TLavUq2oUGn5fA/BoPaXp qavNOB/MIzDfA6I+p61Z732TYbArcCDeJxxWFY3TCRaykgkAjqiTNx4AVaHA/LdhUH Dqmpt52X7zqHZnYWAq/GqtJWKDLgErYRiomxU3VsoqBnYSDQTPi94USoVCCfEajA3Z EhYyFsHDpDF81E+BuNMPRFzTpr9YLFhIlifwF5izDXZBqq4c2OWLGm3P4FfnKvYBxc MAbvYlho1aQhaYVdcbS8nztdR6vwtZe1+4NGESNdUkJrIwF49eNKKsiVGdCZMWuL4l uY00FsGz5ZFBBgAmMa9ApaHtHnH1N9G1Rbak6Q8n2F2r0ionx2EcSCuH9VgqfoRlV3 yJxRAv/hPUYFn7pJpBz1CmKOXTccyWNDTuW9UoG6K3BaNyDkXPo Date: Fri, 8 Apr 2016 21:50:53 +0000 From: "brian m. carlson" To: "openpgp@ietf.org" Message-ID: <20160408215053.GA191287@vauxhall.crustytoothpaste.net> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> X-Machine: Running on vauxhall using GNU/Linux on x86_64 (Linux kernel 4.4.0-1-amd64) User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:59:08 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 08, 2016 at 06:30:07AM +0000, Peter Gutmann wrote: > Bryan Ford writes: > >The whole idea of providing some form of =E2=80=9Cmining-resistance=E2= =80=9D in a fingerprint > >scheme is to enable the key-owner to invest some effort at key-creation = time, > >to ensure that any attacker who wants to try to mine for a key with a si= milar- > >looking fingerprint will have to invest a *lot* more time and effort, no= t just > >a little. >=20 > I'm not sure if this is worth the effort, see "Do Users Verify SSH Keys?", > https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf. T= he > solution isn't to try and patch up something that inherently doesn't work > (look at browser PKI for a twenty-year, and still running, example of try= ing > to do that) but to look for alternative approaches to dealing with the > problem. I agree. I think we're approaching this problem the wrong way. The approach I like is what OpenKeychain is doing with QR codes: you scan the QR code, which contains the fingerprint. No manual verification is necessary. We should design systems that make it easy for people to get right, instead of trying to defeat people being lazy. People are always going to be lazy, and we should aim to have that have as little impact on security as possible. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.11 (GNU/Linux) iQIcBAEBCgAGBQJXCCe8AAoJEL9TXYEfUvaLcPoP/ih33lM1YsZNcirFfTJ6ZODs UBycN86GJlXvEqcQn+SDJvnOj1e4/IDiNWAF0eJJvTPO1Fpv86nhnwjqZApELIb9 Oe6AatIpcK0b7X2XNMcTYIlph8HVWuadr80ebVHs7PtcMjjxMUiCiIfx7R3k1A7P U5PjFad4opzFO9lHFgJkVnFt9QL3jlDxilP14qZ4t0qO8UotxhVmoi0+QGVByvs9 NMLy99hgS9jf/UL4dx0AZP4voCcXMTv+7z7qp0U4K9Q8Zk8AKHxXohGhZ6b0pIFR MqNRql8olt4Vu0S6+FGS0wkDJucZukxpzoZOw/UPcJdEr/4/a8lrhmZMXE5bTP8x AN9Lzh1OiyZC/705kmhrNLzUxcWXLZy90ETWJ1gfDnOoAj4KZbddpVmzKDjJki+x Rr+rgMZ8Xa9l/UzFDqQMJDoaKAhK5MasS0ZIpJwBTp5fYOxmGdxnQp4BEpe9r0ex MZ5J/Ta1sHxkUrSds25SVHRAwSZKjlPaR2x2390E2z9NDupts1QLS3XLmMBbmyTw RgAxLygNBD7dOQBd8eDrBLfE+yN+e/8DGrBF3O0egCLtIK9SvOgLNjDVRw8E+k7E 3Tw7aKjgt0Wp+64XR+esCKt+jBmpSyr89CdiOHx9prP/2EzNHfZ1jdU8XXA8VPVZ OxGWstZ2sCT44rW8lW+h =QElA -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From nobody Fri Apr 8 19:36:10 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129412D614 for ; Fri, 8 Apr 2016 19:36: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 249Te3Nkuv3k for ; Fri, 8 Apr 2016 19:36:08 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 78ADA12D1DC for ; Fri, 8 Apr 2016 19:36:08 -0700 (PDT) Received: from fifthhorseman.net (unknown [201.140.212.132]) by che.mayfirst.org (Postfix) with ESMTPSA id 58DD6FFCB; Fri, 8 Apr 2016 22:36:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BB0E32003D; Fri, 8 Apr 2016 23:35:50 -0300 (ART) From: Daniel Kahn Gillmor To: "brian m. carlson" , "openpgp\@ietf.org" In-Reply-To: <20160408215053.GA191287@vauxhall.crustytoothpaste.net> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> <20160408215053.GA191287@vauxhall.crustytoothpaste.net> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 08 Apr 2016 23:35:50 -0300 Message-ID: <874mbbqzjt.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 02:36:10 -0000 On Fri 2016-04-08 18:50:53 -0300, brian m. carlson wrote: > I agree. I think we're approaching this problem the wrong way. The > approach I like is what OpenKeychain is doing with QR codes: you scan > the QR code, which contains the fingerprint. No manual verification is > necessary. We should design systems that make it easy for people to get > right, instead of trying to defeat people being lazy. People are always > going to be lazy, and we should aim to have that have as little impact > on security as possible. I agree that entirely mechanized, user-friendly, non-MITM-able key transfer is superior to asking humans to deal with fingerprints. But this is not the use case for fingerprints -- we can ignore fingerprints entirely if we're talking about mechanized key transfer (and there's no reason that OpenKeychain needs to use the fingerprint -- for Ed25519 keys, they could just put the public key itself in the QR Code) However, we will still need fingerprints for the use case where people meet up but don't have any machines handy that are capable of doing an automated transfer. We're going to need a transcribable or copy/pasteable string for people to use in that case. We're also going to need such a string for the situations where people want to look up a key in a directory someplace after having done such a non-mechanized transfer. So please, by all means, help people solve the "directory lookup" and "in-person key exchange" use cases in user-friendly ways that do not involve fingerprints. But unless the WG is convinced that those solutions can completely replace the fingerprint everywhere, we'll still need to decide how to compute and structure the fingerprint. The presence of better in-person schemes than fingerprint exchange do suggest that making a complex fingerprint scheme is unlikely to be a good use of the energy of the WG group, though. It would be great to decide on something simple, unambiguous, and secure soon so that we can focus on the harder work we have on our plate. --dkg From nobody Fri Apr 8 19:49:17 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C074A12D54D for ; Fri, 8 Apr 2016 19:49:15 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_yLeOuGO7CF for ; Fri, 8 Apr 2016 19:49:14 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA2712D0A6 for ; Fri, 8 Apr 2016 19:49:14 -0700 (PDT) Received: from fifthhorseman.net (unknown [201.140.212.139]) by che.mayfirst.org (Postfix) with ESMTPSA id 0690010053; Fri, 8 Apr 2016 22:49:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5158A200C9; Fri, 8 Apr 2016 23:49:10 -0300 (BRT) From: Daniel Kahn Gillmor To: Jon Callas , Bryan Ford In-Reply-To: <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 08 Apr 2016 23:49:10 -0300 Message-ID: <87oa9jo5sp.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 02:49:15 -0000 On Fri 2016-04-08 15:32:32 -0300, Jon Callas wrote: > One of the ideas we had a long time ago was that the "fingerprint" > actually has two fields in it. A tag and a value. I'm still fond > myself of the fingerprint that is > > : > > but I'm not wedded to the syntax. I like the idea; I don't care > about the syntax. The sense i got from the group was that we wanted one (and exactly one) fingerprint for any given key. the proposal above means that i could compute a fingerprint for key X, and you could compute a fingerprint for key X, and then when we go to compare them they could be different (because one of us chose a different algorithm id than the other). This makes fingerprint comparison a crapshoot, or requires one side of the comparisons to generate all possible fingerprints before they discover what the other side has done. --dkg From nobody Fri Apr 8 20:15:25 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1712D6B4 for ; Fri, 8 Apr 2016 20:15:23 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOiyj7eFXvkk for ; Fri, 8 Apr 2016 20:15:22 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 703A412D690 for ; Fri, 8 Apr 2016 20:15:22 -0700 (PDT) Received: from fifthhorseman.net (unknown [201.140.212.139]) by che.mayfirst.org (Postfix) with ESMTPSA id 9920810053; Fri, 8 Apr 2016 23:15:19 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2205220072; Sat, 9 Apr 2016 00:15:15 -0300 (BRT) From: Daniel Kahn Gillmor To: Jon Callas , Bryan Ford In-Reply-To: <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sat, 09 Apr 2016 00:15:14 -0300 Message-ID: <87fuuvo4l9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 03:15:24 -0000 On Thu 2016-04-07 20:33:56 -0300, Jon Callas wrote: > Yes, because I can tell you that it's *really* useful to be able to > reuse the key material from alice@example.com for (e.g.) > jobs@example.com or security, or whatever. I've done it a lot over > the years. What is the utility here, specifically? I appreciate making tracking/linkability harder as a goal, but i'm not conivnced that this achieves that purpose. Anyone who has the keys for alice@example.com and jobs@example.com can tell that these are the same keys, and can just join them in their linkability/trackability database. Furthermore, it introduces additional management problems for Alice; if she loses control of the secret key material, she now has to ensure that she's generated a revocation certificate for each "flavor" of it, because the revocations are bound to the same material that the fingerprint is bound to. If the revocation were bound to the public key material, then Alice could revoke once and be done with it. New keys are cheap enough that Alice should be able to solve the linkability problem y just having an entirely separate key for jobs@example.com, no? --dkg From nobody Fri Apr 8 21:07:48 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10F312D0C4 for ; Fri, 8 Apr 2016 21:07:46 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6L2WEd3YKOd for ; Fri, 8 Apr 2016 21:07:45 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDFA12D724 for ; Fri, 8 Apr 2016 21:07:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 985259473DB8; Fri, 8 Apr 2016 21:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzvSIVDZl+-s; Fri, 8 Apr 2016 21:07:34 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 52D179473DA0; Fri, 8 Apr 2016 21:07:34 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 08 Apr 2016 21:07:34 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 08 Apr 2016 21:07:34 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: <87fuuvo4l9.fsf@alice.fifthhorseman.net> Date: Fri, 8 Apr 2016 21:07:33 -0700 Message-Id: <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> <87fuuvo4l9.fsf@alice.fifthhorseman.net> To: openpgp@ietf.org X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jon Callas Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 04:07:46 -0000 > On Apr 8, 2016, at 8:15 PM, Daniel Kahn Gillmor = wrote: >=20 > On Thu 2016-04-07 20:33:56 -0300, Jon Callas wrote: >> Yes, because I can tell you that it's *really* useful to be able to >> reuse the key material from alice@example.com for (e.g.) >> jobs@example.com or security, or whatever. I've done it a lot over >> the years. >=20 > What is the utility here, specifically? >=20 > I appreciate making tracking/linkability harder as a goal, but i'm not > conivnced that this achieves that purpose. Let me rewind then. PGP 2 had key-canonical fingerprints. There were = issues with them. Nothing particularly horrible, but they we all of the = sort of fun and games that you can play with the emergent properties of = hash functions. And really, I can't remember them all that well because = that was ages ago. PGP 3 and thus OpenPGP threw the creation time in there as a quickie = salt. I didn't do it. I don't know the full reasons.=20 I originally thought this was dumb. I got turned around, and believe = that salting the hash is a good thing. I know that I have used this = property so that I can re-use key material, but it's not the total = reason. I can think of a bunch of half-assed things someone can do with = key-canonical fingerprints if they are, say, the NSA. Nothing that's an = attack, but just stuff. If anything, I think that salting the hash ought to be with more than = the timestamp. But really, I'd keep the fingerprint computation the = same, just with a more modern algorithm than SHA-1. The problem we're = trying to solve is that SHA-1 is old. I like to change only one knob at = a time. Most of all, I think that semantic properties like this shouldn't change = without a reason. At present, there are uses, questionable as they are, = for this, and why break it just because? Right now, we know that for every fingerprint there is a key (modulo = hash collisions), but a key can have many fingerprints. Why to we want = to change it so that there's one-to-one correspondence between keys and = fingerprints? This sounds to me like it's vaguely surveillance-friendly. >=20 > Anyone who has the keys for alice@example.com and jobs@example.com can > tell that these are the same keys, and can just join them in their > linkability/trackability database. >=20 > Furthermore, it introduces additional management problems for Alice; = if > she loses control of the secret key material, she now has to ensure = that > she's generated a revocation certificate for each "flavor" of it, > because the revocations are bound to the same material that the > fingerprint is bound to. So? The reason to break the binding between key material and a = certificate is so that there's no binding. Actually -- this sounds like as much a reason to salt it. There are more = reasons to revoke than loss of key material, and this means that = revocation is even less useful. Jon From nobody Fri Apr 8 22:35:55 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EECE12D183 for ; Fri, 8 Apr 2016 22:35:54 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DVzCYfBUEUF for ; Fri, 8 Apr 2016 22:35:52 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3412D0BE for ; Fri, 8 Apr 2016 22:35:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id F12819474D0D; Fri, 8 Apr 2016 22:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdewC2mU8zxs; Fri, 8 Apr 2016 22:35:50 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 7CABC9474CF9; Fri, 8 Apr 2016 22:35:49 -0700 (PDT) Received: from [10.0.23.7] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 08 Apr 2016 22:35:50 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 08 Apr 2016 22:35:50 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: <87oa9jo5sp.fsf@alice.fifthhorseman.net> Date: Fri, 8 Apr 2016 22:35:49 -0700 Message-Id: <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, Jon Callas , Bryan Ford Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 05:35:54 -0000 > On Apr 8, 2016, at 7:49 PM, Daniel Kahn Gillmor = wrote: >=20 > On Fri 2016-04-08 15:32:32 -0300, Jon Callas wrote: >> One of the ideas we had a long time ago was that the "fingerprint" >> actually has two fields in it. A tag and a value. I'm still fond >> myself of the fingerprint that is >>=20 >> : >>=20 >> but I'm not wedded to the syntax. I like the idea; I don't care >> about the syntax. >=20 > The sense i got from the group was that we wanted one (and exactly = one) > fingerprint for any given key. >=20 > the proposal above means that i could compute a fingerprint for key X, > and you could compute a fingerprint for key X, and then when we go to > compare them they could be different (because one of us chose a > different algorithm id than the other). This makes fingerprint > comparison a crapshoot, or requires one side of the comparisons to > generate all possible fingerprints before they discover what the other > side has done. Noted. I will mention that the advantage of a generic scheme is that it doesn't = have to be revisited later when there's a new cool hash function that we = all should use. But the real reason for bringing that back was to give Bryan a hand. I = see what he's wanting to do. He's wanting to create something that I = will call the "authentication string."=20 At present, we use the key fingerprint as the authentication string. The = mining protection he's suggesting isn't a bad thing. My raised eyebrow = comes from conflating the two. We need to have a "DB handle" and I = believe the DB handle needs to be easy to compute (key-canonical is an = orthogonal issue). The fingerprint gets used all over the place, = especially in its truncated form as key-id. So a way to get both is to make them not the same thing. Have it so that = the thing that you print on your business card is the authentication = string, and the thing that the software is using a lot is the db handle. As it is, there are "fingerprints" used all over the place that aren't = the user-visible one anyway, because the user-visible one is the = fingerprint of the top-level signing key. So stepping back even further, to have our cake and eat it two, we want = to separate the two functions. Anything that does that seems like a win, not just generalized = fingerprints. Jon= From nobody Sat Apr 9 02:50:28 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4975012D515 for ; Sat, 9 Apr 2016 02:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQlNUaaT1HA3 for ; Sat, 9 Apr 2016 02:50:24 -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 EB15812D4FD for ; Sat, 9 Apr 2016 02:50:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aopX3-0001Xk-9y for ; Sat, 09 Apr 2016 11:50:21 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aopWk-0007Oh-Un; Sat, 09 Apr 2016 11:50:02 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> <20160408215053.GA191287@vauxhall.crustytoothpaste.net> <874mbbqzjt.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Daniel Kahn Gillmor , "brian m. carlson" , "openpgp\@ietf.org" Date: Sat, 09 Apr 2016 11:50:02 +0200 In-Reply-To: <874mbbqzjt.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 08 Apr 2016 23:35:50 -0300") Message-ID: <87egafkt6d.fsf@wheatstone.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" , "brian m. carlson" Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 09:50:27 -0000 On Sat, 9 Apr 2016 04:35, dkg@fifthhorseman.net said: > (and there's no reason that OpenKeychain needs to use the fingerprint -- > for Ed25519 keys, they could just put the public key itself in the QR Which would also encourage not to add a salt (creation timestamp) so that there is no need to somehow also convey the creation timestamp. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat Apr 9 06:55:51 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950A812D6CF for ; Sat, 9 Apr 2016 06:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_LDCvmcX95c for ; Sat, 9 Apr 2016 06:55:46 -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 9D5EE12D694 for ; Sat, 9 Apr 2016 06:55:45 -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=1460210145; x=1491746145; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sNqyVR9OKxllhD3Fq3rB606THidndPUtzK2L2pd0z9Y=; b=fnEDIqPbRejrFPR5OJFyJ4O31ZbyZLqXsaa74bQgE4KvmNE48oXqIUKt cOTN+nzUc5OoKvtQEilxXSnmB+lIj7zjz3dxgDZfc/WDLFKlKBafDqNlL xWk+p6AGGZirgFvVqMWWEMMTW5zoZ/qXaGuMPJIVNMQfa50H+eOVdMRet bXdSLoC6oWCM8VYrnTLkQPRbkn3ARjf5UkPm1SZXvK6/5Vos1VJmSbK4Z m+uLLRBXmgH/VaGkr1Coc/23YkLPc0Xgw3Io67qKmDzm78cAaUonsTG3r lTSGVhqn4LwQvaHSYl65bL6BM6NwBgFuX9vbVm6y6mQvglSOrs55clq5c g==; X-IronPort-AV: E=Sophos;i="5.24,454,1454929200"; d="scan'208";a="79124462" 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/AES256-SHA; 10 Apr 2016 01:55:43 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Sun, 10 Apr 2016 01:55:42 +1200 From: Peter Gutmann To: "brian m. carlson" , "openpgp@ietf.org" Thread-Topic: [openpgp] Mining protection in fingerprint schemes Thread-Index: AQHRkD712bG2iqLU6EOL6HNGn5mjH598wM8AgAEQngCAAc4v04AAOC2AgAHWfV0= Date: Sat, 9 Apr 2016 13:55:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C52D38@uxcn10-5.UoA.auckland.ac.nz> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz>, <20160408215053.GA191287@vauxhall.crustytoothpaste.net> In-Reply-To: <20160408215053.GA191287@vauxhall.crustytoothpaste.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 13:55:50 -0000 brian m. carlson writes:=0A= =0A= >The approach I like is what OpenKeychain is doing with QR codes: you scan = the=0A= >QR code, which contains the fingerprint. No manual verification is=0A= >necessary. We should design systems that make it easy for people to get=0A= >right, instead of trying to defeat people being lazy.=0A= =0A= Exactly, leave the computation to the computers. No human should be expect= ed=0A= to compare 40 hex digits for an exact match, that's why we have computers. = In=0A= fact the denser QR codes can store an entire key in the QR code. Once it's= on=0A= your phone, you can use your method of choice to get it to other devices.= =0A= =0A= Peter.= From nobody Sat Apr 9 07:02:34 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E912D6E6 for ; Sat, 9 Apr 2016 07:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwTBATi89liG for ; Sat, 9 Apr 2016 07:02:31 -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 2211112D6D6 for ; Sat, 9 Apr 2016 07:02:30 -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=1460210551; x=1491746551; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y5Q+Wgkixia0QYn7995WqXbJWnF1CKAXTTifcwkJFjk=; b=1JCkDN9K657M9mOqEVQVDpF18mr06JehC91xRjzrxHhe9IUoZ6CuAal8 UUS97+Mp1oXgJjVM1Zz5BlqOJZXgpXL6uH2bCGMuqbAuk3VIzpeCUHfN+ 4m+xMbsh6zp3wdOkL+HRwBaAcomlTdzJ81oQw/x11fjrCfmNoD0i7GqIN JHaKjTp03bXt+bRIWMCisjCvqljRrRnHKggvLqqqcT9TWLtLDmbDzPRcH f8ndDpeFMKuASqEeRqjlk0mrSjUn6AduirVN0BrSMj2h16vUdQn/oscoP T6ZPahT71ntEgvIEI51In+rAJ7LXtmAGt0IXn1QPrM4jN/nO6DRjibfpW A==; X-IronPort-AV: E=Sophos;i="5.24,454,1454929200"; d="scan'208";a="79124827" 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/AES256-SHA; 10 Apr 2016 02:02:29 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Sun, 10 Apr 2016 02:02:29 +1200 From: Peter Gutmann To: Jon Callas , Daniel Kahn Gillmor Thread-Topic: [openpgp] Mining protection in fingerprint schemes Thread-Index: AQHRkD712bG2iqLU6EOL6HNGn5mjH598wM8AgAEQngCAAJFwgIAAGs8AgAEisgCAAIrCAIAALo+AgAFWM0U= Date: Sat, 9 Apr 2016 14:02:29 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C53D55@uxcn10-5.UoA.auckland.ac.nz> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net>, <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> In-Reply-To: <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 14:02:33 -0000 Jon Callas writes:=0A= =0A= >So a way to get both is to make them not the same thing. Have it so that t= he=0A= >thing that you print on your business card is the authentication string, a= nd=0A= >the thing that the software is using a lot is the db handle.=0A= =0A= That would resolve my pet peeve with the authent strings. It'd also requir= e=0A= modifying the keyring format to store the keyID as part of the keyring data= =0A= rather than requiring that the software processing it calculate the ID for= =0A= every single key it finds in a keyring in case it's the required one. At t= he=0A= moment PKCS #15 is actually a better PGP keyring format than the native PGP= =0A= one because it stores PGP 2/OpenPGP IDs that you can use to index the keys = in=0A= a file without having to process the entire keyring and manually calculate = the=0A= ID for every key in it just to find a particular key.=0A= =0A= Peter.= From nobody Sat Apr 9 08:56:38 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757F912B02D for ; Sat, 9 Apr 2016 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqB7tm_t3z1G for ; Sat, 9 Apr 2016 08:56:35 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 8C5D012B02C for ; Sat, 9 Apr 2016 08:56:35 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id j35so113572405qge.0 for ; Sat, 09 Apr 2016 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=q6futV1Zyv1M7UcvWAiG8OVRhEVLFokbrJ/uS1+f9nU=; b=zujE9dyQvdG3Ku419WSPtl3Txx41SXUn2S0TEeRFHKPq4S5i8BtqUILEf4HXDbdEGo Ru/KtGWnE3QtBQtiHIXkYDG/6KfUHJLafEN2FXInxxKbFgxq+fWOkjZtnvW/i7Hg7CcP 7A/LokBiGyTjMH2gjMLNVb84N6fi/phXmPs3BVLc//v7g1RqUeBjJ9l9zBrwbXkOq9Hq qwluwcSqG22wTxK/YyCyz1Htbw+QX0F5/fWY/4p6Uk9ekWvgY8FHPvFwEinht0BaJp7/ tHEL2Mo9VtocZcLX6Lgx1cEZJ7tpRWe0nQbbiGSqPAWAPyw9etZAdUxuMF67cNYslQ0m MFGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=q6futV1Zyv1M7UcvWAiG8OVRhEVLFokbrJ/uS1+f9nU=; b=QPZqj4P9ng2mNqCH+rG5DXH20B6xotQ8CgIwnUCqGIY9Wwd+xukQQN/NYCrYgM8Auf MuqvfOvi1wZq8596zTa1aqM1FYtUM1CZk1fHO48HDmRURA4+prkwwwdB3H8wTxoqIhoO H8c8tiQQ+A/aQOxXvbsgAljLxGiQITB4kpVI9N3kiQGeATPfdNjrWO7S7i+oi0U0Hz8p Woop1e3MU8La3tZfQPHoznFv/DZJROC4Ydo+j6eRh+URXhD1aFTM0RK03V/KurJlCWto OmDUMGvA/XV3xyc6BUOAhJTJa/kO9eBrGxa4//ODpWb7gpvLYvRkUNtDgYpl2fcHQeiI 6GrQ== X-Gm-Message-State: AD7BkJIKZHCBDq2O5LX05owXbL4CbGMljoTIbb6ebMcv19rLHxzqZXnSuQ55eyslMqmz9Q== X-Received: by 10.140.234.151 with SMTP id f145mr19865515qhc.51.1460217394430; Sat, 09 Apr 2016 08:56:34 -0700 (PDT) Received: from [192.168.1.194] ([201.177.20.11]) by smtp.gmail.com with ESMTPSA id 64sm7595184qhf.40.2016.04.09.08.56.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Apr 2016 08:56:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_695D30C0-3088-434A-B816-F9D5EC08FABC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> Date: Sat, 9 Apr 2016 12:55:42 -0300 Message-Id: <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 15:56:37 -0000 --Apple-Mail=_695D30C0-3088-434A-B816-F9D5EC08FABC Content-Type: multipart/alternative; boundary="Apple-Mail=_1BF0D263-43B2-449C-A96A-E7BD24971F14" --Apple-Mail=_1BF0D263-43B2-449C-A96A-E7BD24971F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 9, 2016, at 2:35 AM, Jon Callas wrote: > At present, we use the key fingerprint as the authentication string. = The mining protection he's suggesting isn't a bad thing. My raised = eyebrow comes from conflating the two. We need to have a "DB handle" and = I believe the DB handle needs to be easy to compute (key-canonical is an = orthogonal issue). The fingerprint gets used all over the place, = especially in its truncated form as key-id. I agree that =E2=80=9Cfingerprints=E2=80=9D used purely as internal = DB-handles or indexes are a separate purpose from =E2=80=9Cfingerprints=E2= =80=9D presented to users and displayed on business cards and websites, = and it may well be worth treating them separately. With that in mind, here=E2=80=99s one terminology suggestion. Previous = versions of PGP by default tend to use small, weak somethings it calls = =E2=80=9Ckey IDs=E2=80=9D as the normal user-presentation form of = fingerprints. We know that encouraging users to depend on key IDs for = anything - or even to understand that =E2=80=9CKey ID=E2=80=9D = collisions are possible and eminently mineable - and hence we know that = =E2=80=9CKey IDs=E2=80=9D of this kind need to die. =20 But if we consider =E2=80=9CPGP tradition=E2=80=9D terminology to be = that =E2=80=9Cfingerprints=E2=80=9D are supposed to be full-length DB = handles for internal use, whereas =E2=80=9Ckey IDs=E2=80=9D are = something related but different for user display and consumption, we = could make both of them better in V5 while preserving this terminology = convention. In particular: - V5 =E2=80=9Cfingerprint" is just a raw SHA384 or SHA512 hash of the = key material (with or without timestamp or other stuff, depending on the = WG=E2=80=99s decision on that orthogonal issue). This is the = =E2=80=9CDB-handle=E2=80=9D. It=E2=80=99s never expected to be = presented into the user or put on business cards. - V5 =E2=80=9Ckey ID=E2=80=9D is derived from the V5 fingerprint and = shortened for presentation to the user - but shortened only to ~256 = bits, not shortened to the point of insecurity like V3/V4 key IDs are. = That shortening could easily include simple Key ID mining-protection. This would make new =E2=80=9CKey IDs=E2=80=9D actually safe to use for = the purposes they tend to get used for, while avoiding the usage = conflation with the =E2=80=9CDB handle=E2=80=9D purpose of fingerprints. = PGP implementations could go on displaying =E2=80=9Ckey IDs=E2=80=9D by = default when listing keys, only for V5 keys these key IDs would now be = long enough to provide meaningful protection. What is the actual function from =E2=80=9Cfingerprint=E2=80=9D to =E2=80=9C= key ID=E2=80=9D? Three alternatives spring to mind: 1. Truncation, from 384 or 512 bits to 256. Trivial but offers no = possibility of Key-ID mining protection. 2. Simple mining protection: Key ID is one digit representing number of = leading zero hex digits in fingerprint, followed by encoded final 256 = bits of fingerprint. Basically PHB=E2=80=99s suggestion. 3. Memory-hardened mining protection: use fingerprint as nonce for a = small Argon2 run, then SHA384 or SHA512 hash the output of that, and = finally encode as in option 2 above (one-digit representing number of = leading zeros followed by encoding of last 256 bits). All of these alternatives allow the =E2=80=9Cfingerprint=E2=80=9D to be = used as an internal DB-handle with no added complexity or inefficiency, = while adding only a rather small amount of complexity and cost purely to = the conversion from internal-purposed =E2=80=9Cfingerprint=E2=80=9D to = user-presentation-oriented =E2=80=9Ckey ID=E2=80=9D. If the WG = doesn=E2=80=99t perceive the added protection of memory-hardening in = option 3 is worth the costs, then option 2 would seem at least to me to = have pretty much negligible cost. Bryan --Apple-Mail=_1BF0D263-43B2-449C-A96A-E7BD24971F14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 9, 2016, at 2:35 AM, Jon Callas <jon@callas.org> = wrote:
At present, we use the key fingerprint as = the authentication string. The mining protection he's suggesting isn't a = bad thing. My raised eyebrow comes from conflating the two. We need to = have a "DB handle" and I believe the DB handle needs to be easy to = compute (key-canonical is an orthogonal issue). The fingerprint gets = used all over the place, especially in its truncated form as = key-id.

I agree = that =E2=80=9Cfingerprints=E2=80=9D used purely as internal DB-handles = or indexes are a separate purpose from =E2=80=9Cfingerprints=E2=80=9D = presented to users and displayed on business cards and websites, and it = may well be worth treating them separately.

With that in mind, here=E2=80=99s one terminology = suggestion.  Previous versions of PGP by default tend to use small, = weak somethings it calls =E2=80=9Ckey IDs=E2=80=9D as the normal = user-presentation form of fingerprints.  We know that encouraging = users to depend on key IDs for anything - or even to understand that = =E2=80=9CKey ID=E2=80=9D collisions are possible and eminently mineable = - and hence we know that =E2=80=9CKey IDs=E2=80=9D of this kind need to = die.  

But if we consider = =E2=80=9CPGP tradition=E2=80=9D terminology to be that = =E2=80=9Cfingerprints=E2=80=9D are supposed to be full-length DB handles = for internal use, whereas =E2=80=9Ckey IDs=E2=80=9D are something = related but different for user display and consumption, we could make = both of them better in V5 while preserving this terminology = convention.

In = particular:

- V5 =E2=80=9Cfingerprint"= is just a raw SHA384 or SHA512 hash of the key material (with or = without timestamp or other stuff, depending on the WG=E2=80=99s decision = on that orthogonal issue).  This is the =E2=80=9CDB-handle=E2=80=9D. =  It=E2=80=99s never expected to be presented into the user or put = on business cards.

- V5 =E2=80=9Ckey = ID=E2=80=9D is derived from the V5 fingerprint and shortened for = presentation to the user - but shortened only to ~256 bits, not = shortened to the point of insecurity like V3/V4 key IDs are.  That = shortening could easily include simple Key ID = mining-protection.

This would make = new =E2=80=9CKey IDs=E2=80=9D actually safe to use for the purposes they = tend to get used for, while avoiding the usage conflation with the =E2=80=9C= DB handle=E2=80=9D purpose of fingerprints.  PGP implementations = could go on displaying =E2=80=9Ckey IDs=E2=80=9D by default when listing = keys, only for V5 keys these key IDs would now be long enough to provide = meaningful protection.

What is the = actual function from =E2=80=9Cfingerprint=E2=80=9D to =E2=80=9Ckey = ID=E2=80=9D?  Three alternatives spring to mind:

1. Truncation, from 384 or 512 bits to 256. =  Trivial but offers no possibility of Key-ID mining = protection.

2. Simple mining = protection: Key ID is one digit representing number of leading zero hex = digits in fingerprint, followed by encoded final 256 bits of = fingerprint.  Basically PHB=E2=80=99s suggestion.

3. Memory-hardened = mining protection: use fingerprint as nonce for a small Argon2 run, then = SHA384 or SHA512 hash the output of that, and finally encode as in = option 2 above (one-digit representing number of leading zeros followed = by encoding of last 256 bits).

All of these alternatives allow the = =E2=80=9Cfingerprint=E2=80=9D to be used as an internal DB-handle with = no added complexity or inefficiency, while adding only a rather small = amount of complexity and cost purely to the conversion from = internal-purposed =E2=80=9Cfingerprint=E2=80=9D to = user-presentation-oriented =E2=80=9Ckey ID=E2=80=9D.  If the WG = doesn=E2=80=99t perceive the added protection of memory-hardening in = option 3 is worth the costs, then option 2 would seem at least to me to = have pretty much negligible cost.

Bryan

= --Apple-Mail=_1BF0D263-43B2-449C-A96A-E7BD24971F14-- --Apple-Mail=_695D30C0-3088-434A-B816-F9D5EC08FABC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDkxNTU2MDNaMCMGCSqGSIb3DQEJBDEWBBTczpcJ2PDhWLi/UfAf6YGipQ3kEjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAfSEm6eGbboIKYH+fTkNo+MVje7lDJsntg8MxLIjphV/4aGP/wbFNmqhVnsTSvpms 0PQkCr00FsC7Tjdb+Wt0GO8LHMUlTbIItsAEmvPypTMU65qSyciJXkMbXxXWHO6dz/ZKhGM+HNyz DwK/Mv2JCfF2Nu06bMqjIljNEjqn4L+/AFM9atWj/8DU0jxyWQXUOnT0LIkajA6DzWde/vkwENJF u9dTXvIJQpcwoDb6CuV5DOnc3OI/YPWQA/niKbY01/6qyexW3a7OWXgikEMbUgxtSJZnCxGcJ1CP vEC9U3lIXY8hlDuQ63PYzVIYgGBHF9TehxuCow7/YHbPmtfAowAAAAAAAA== --Apple-Mail=_695D30C0-3088-434A-B816-F9D5EC08FABC-- From nobody Sat Apr 9 09:03:35 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2135712B02C for ; Sat, 9 Apr 2016 09:03:34 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTU5lOwCkM3q for ; Sat, 9 Apr 2016 09:03:32 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 A25BC12B02E for ; Sat, 9 Apr 2016 09:03:32 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id c6so113685453qga.1 for ; Sat, 09 Apr 2016 09:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5lNG4GbuI0JiBhJSJUJ/mskNkoI+Fk5mNU4F5qCWYKk=; b=SvJQsBMAnh6HrcKKYgecPjWkfFAoypkDU6M9dXZ8YRzFKQsmiiGKAx+4UcDYdl6Hur rGgdEMrH5iUF/tEoFgfH7uqFF7IulHHybV+gXP84VS28NzXYXuWf7DxVg6L3aEJSLN50 QpXTxNaOqsvjSecFIJcCx1HDqiR4376iUK9om3ZfC71JE9bMHHTe40B6LLDh21Xnw0fD 6+MPvJ0XgldtlOSwHvgFFftTCdFtuXwQg9JAqDDzsmlnPDC/42Yjs5RmIy1+wmNNtmhd U5TEFSHWK7Ju5yGLlB7nXG1AYUCwZOwzoTUBsrmUvMb0t94fZCsL1hMdG45BFUd2Nqy/ iS7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5lNG4GbuI0JiBhJSJUJ/mskNkoI+Fk5mNU4F5qCWYKk=; b=j+Q+xYhM7bB/whdiM8if6uxtwygiCkcJLaOjZZTghOFhGVn+Z5JfBJLx5kDuUls2RQ K3zvHQyCSD/+CnO+Pd2eBD+g/HiZrDAyY8hEHP4UQVdqejSojk5fzrHWiWNM9vVdtodM v5EVzn2wXlcOBeAjwWIho06pV5FoQFjZrv7wQgBKoUtv3qKAdL9BCNaIoiGqJ78yYdBL VzNXjDIoRwAeUYNq6xULep9+z1MKPmPhcxBU+r68d5naI8h3JISv5wxcIU/32VgLoeOL +tlg2qtxjZAux1E16HDehFx0xtLuPqrgiBsjdbZ8LtUAxepyrlY3gtlcul4xZI060f7Q R80g== X-Gm-Message-State: AD7BkJJCAfrHemvu8D3jLVxASg4uGLMMcB96Bk5KgNfH0qPd90LN0JA5UxlUcPRsfAekfw== X-Received: by 10.140.242.77 with SMTP id n74mr19967574qhc.2.1460217811604; Sat, 09 Apr 2016 09:03:31 -0700 (PDT) Received: from [192.168.1.194] ([201.177.20.11]) by smtp.gmail.com with ESMTPSA id b132sm1846045qkg.3.2016.04.09.09.03.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Apr 2016 09:03:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FF7141D2-902D-4677-A1AB-069AAEC977C8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <874mbbqzjt.fsf@alice.fifthhorseman.net> Date: Sat, 9 Apr 2016 12:58:15 -0300 Message-Id: <6A42DA30-F22C-4323-8E18-A3089277DCFF@gmail.com> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> <20160408215053.GA191287@vauxhall.crustytoothpaste.net> <874mbbqzjt.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "openpgp@ietf.org" , "brian m. carlson" Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 16:03:34 -0000 --Apple-Mail=_FF7141D2-902D-4677-A1AB-069AAEC977C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 8, 2016, at 11:35 PM, Daniel Kahn Gillmor = wrote: > So please, by all means, help people solve the "directory lookup" and > "in-person key exchange" use cases in user-friendly ways that do not > involve fingerprints. But unless the WG is convinced that those > solutions can completely replace the fingerprint everywhere, we'll = still > need to decide how to compute and structure the fingerprint. +1. I love user-friendly interactive key-verification mechanisms for = the use-cases they apply to, and worked on them as part of my PhD for = example. But until they=E2=80=99re so usable and ubiquitously-deployed = that no one needs to put their PGP key fingerprint on their business = card or web site anymore, we still need to care at least a little bit = about fingerprints that can be put on business cards and websites. B= --Apple-Mail=_FF7141D2-902D-4677-A1AB-069AAEC977C8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDkxNTU4MTVaMCMGCSqGSIb3DQEJBDEWBBTJLZXqRZr0ote89TcLbmXpC/j3/DCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAOWXdVYNCkfFg/6J381QOuUveKeQHaP/ht+EjpcVZfpNCp7rHd1G2QFMH+P4bNI0K asvLxMAHUkusgqPHfdkFyekxQ2mUGEYZ9wBCGXEi4PHnx3WDjODlMaOFpys6wiejec4DY3ZHCZJ0 zb48gScKTk9aMTdP3VanVy8BturfmxgTakjp0PPptjz3saAojG67kaMivds8maVGasa1AMXVD6s1 Arw+BHLFC7pN12DqvaUO1Qa1h+XvyRUoUslNrkcrtID/J+HBrEHF1UbsQfJKvRAoFAUUw2+ACtf6 4BDGkkGZ71zCtQI9x67kOWeEq2AKtxUpr1cT5OodBMnESkm+8wAAAAAAAA== --Apple-Mail=_FF7141D2-902D-4677-A1AB-069AAEC977C8-- From nobody Sat Apr 9 09:03:49 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8712B03A for ; Sat, 9 Apr 2016 09:03:46 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg9WXJl5pdu4 for ; Sat, 9 Apr 2016 09:03:39 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 2CC0512B03B for ; Sat, 9 Apr 2016 09:03:39 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id i4so55458830qkc.3 for ; Sat, 09 Apr 2016 09:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tDdjxCkV8ohyY/gGIt8nRAZwCc8xhTurAbW5CWsdUW4=; b=L8ZLzCY4PYPopMm7qCruamCEytn5LiAIO19mOK3YOx7znSQhQP57A3FyoSID3jBl6V cXlROZ6Z4oVr0PaWssmO/Y+o2vDM1nY3Dee0wQSSjofsfUGaN/Wq6t4UjKbr9mn9U9xy UfN8sZ5iDf3ZJexgHqW3eXKWD4zUpRJ3v9T+W2MD+RttTcwsZ0okcBIuS43EOKj/c0K3 xm0Pn0NaTkG88Ry2exokbO7oz206OFwbEQ4ujzcfmvDnIp+DckZZKdQFA6TH/qsKFwSQ DotMD2Pedi7nGejjTmq6ksy7Not4hMcFyhpJBggxZXFty3FBw/R2znZyGNySWULSNfR9 nT6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tDdjxCkV8ohyY/gGIt8nRAZwCc8xhTurAbW5CWsdUW4=; b=X8YGuEDFmer65kcCoIO2M7w357iW9ynWExPEDDvebAbWyIjiZ5GI+PQXXMzGYd+DY8 Pf94qb8eC3H3OEI451NecBAAvVXNahrB0pfSJFF3TOJShUE/mSmVDcHYTU/E6CgBRghh YyXz7J9USwhltlMngNMQL+xSXL8lLSS/QM9iYBG7fqm97UNYWe1fUlb6Eu094e/zXdx6 esI1+P/0hBXv+OTGaXjDKLgaIUCaU9dtHgBlmsfLhk1ZMa5wKtY33EL5LxKM2SeTY0JI sWiP+MHMxYtyo4tOz/d1YzbJnkhh2H9exnZernsGT23hvf3+JL6E+mr9GzxoADgGEmtv azHg== X-Gm-Message-State: AOPr4FVH1cmcNmgGrrb5zZ1fEmw350lIm39ckHzEA7OXPPP+2ZEuI+okQhz0UX1vwhuK2g== X-Received: by 10.55.11.137 with SMTP id 131mr10488235qkl.51.1460217818267; Sat, 09 Apr 2016 09:03:38 -0700 (PDT) Received: from [192.168.1.194] ([201.177.20.11]) by smtp.gmail.com with ESMTPSA id b132sm1846045qkg.3.2016.04.09.09.03.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Apr 2016 09:03:37 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_991D2856-3321-4A44-ACA0-02A1EC23A615"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <874mbbqzjt.fsf@alice.fifthhorseman.net> Date: Sat, 9 Apr 2016 12:58:43 -0300 Message-Id: References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> <20160408215053.GA191287@vauxhall.crustytoothpaste.net> <874mbbqzjt.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "openpgp@ietf.org" , "brian m. carlson" Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 16:03:47 -0000 --Apple-Mail=_991D2856-3321-4A44-ACA0-02A1EC23A615 Content-Transfer-Encoding: 7bit Content-Type: text/plain --Apple-Mail=_991D2856-3321-4A44-ACA0-02A1EC23A615 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA0MDkxNTU4NDRaMCMGCSqGSIb3DQEJBDEWBBSvljt9wHoXlByKf+2elzXQMonxxjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAvoaRjgNBLIapS5N6ZA4DVZjY9ogTlwKU4OxFeBW6z3owJRdNmFlLozxS+fO5bawU 8T1LhvA7UtzwphdaJBJuw9C2RAgO/e9fXe4aw5PR0iUp6zM0GltQFO/y8by2fcekXp5DJUdsuVUj KR7PZklaHMIfGfqavH9GxMp8jmQlOINDTrJzdb72bCEydmmKb1P8FvtnN0FY2q1V5f3Nn9g6jFtR lcsNYTsv/N8Ew+ePnmJMQjHifwHfSpSH+QsDWkCDRKOzNHqXqrcgn1LyHgv3fz5C83JIMnR7HZks rIZfm82x7v5ZMRsuXqo9qzESB81d+67gTUkZoToYCtvE7gTOfgAAAAAAAA== --Apple-Mail=_991D2856-3321-4A44-ACA0-02A1EC23A615-- From nobody Sat Apr 9 12:09:52 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774712D113 for ; Sat, 9 Apr 2016 12:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEbPdT427wxu for ; Sat, 9 Apr 2016 12:09:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C433A12D10F for ; Sat, 9 Apr 2016 12:09:50 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 82B12FF57; Sat, 9 Apr 2016 15:09:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 79EC71FFD1; Sat, 9 Apr 2016 15:09:48 -0400 (EDT) From: Daniel Kahn Gillmor To: Jon Callas , openpgp@ietf.org In-Reply-To: <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> <87fuuvo4l9.fsf@alice.fifthhorseman.net> <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sat, 09 Apr 2016 15:09:48 -0400 Message-ID: <87mvp2vbsz.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 19:09:51 -0000 On Sat 2016-04-09 00:07:33 -0400, Jon Callas wrote: > Right now, we know that for every fingerprint there is a key (modulo > hash collisions), but a key can have many fingerprints. Why to we want > to change it so that there's one-to-one correspondence between keys > and fingerprints? This sounds to me like it's vaguely > surveillance-friendly. i think if people want messages to be sent to different fingerprints, we should be encouraging them to have different keys entirely, no? >> On Apr 8, 2016, at 8:15 PM, Daniel Kahn Gillmor wrote: >> >> Anyone who has the keys for alice@example.com and jobs@example.com can >> tell that these are the same keys, and can just join them in their >> linkability/trackability database. >> >> Furthermore, it introduces additional management problems for Alice; if >> she loses control of the secret key material, she now has to ensure that >> she's generated a revocation certificate for each "flavor" of it, >> because the revocations are bound to the same material that the >> fingerprint is bound to. > > So? The reason to break the binding between key material and a certificate is so that there's no binding. if the goal is to break the binding between the key material and the identity information in the certificate, the right OpenPGP mechanism is to revoke the User ID, not to revoke the primary key. The use case i described was an attempt to revoke the primary key entirely. > Actually -- this sounds like as much a reason to salt it. There are > more reasons to revoke than loss of key material, and this means that > revocation is even less useful. If the primary goal of key revocation is to render a key permanently unusuable, then it would be good to be very clear about that, and not have too many other things that it might mean. I'm leaning in the direction that if you want to "retire" a key without revoking it, you should do so by setting the expiration date to "now", and not by publishing a revocation at all. That way, direct key revocations are less complex to reason about, because they mean exactly one thing. --dkg From nobody Sat Apr 9 12:45:37 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D7612D0F3 for ; Sat, 9 Apr 2016 12:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jeR91EWa-Nx for ; Sat, 9 Apr 2016 12:45:33 -0700 (PDT) Received: from mail.hashbang.sh (mail.hashbang.sh [104.236.230.244]) (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 888A412D0E0 for ; Sat, 9 Apr 2016 12:45:33 -0700 (PDT) Received: from to1.hashbang.sh (to1.hashbang.sh [104.245.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hashbang.sh (Postfix) with ESMTPS id 4E46E37C4; Sat, 9 Apr 2016 19:45:32 +0000 (UTC) Received: by to1.hashbang.sh (Postfix, from userid 3412) id D440BE00BA; Sat, 9 Apr 2016 19:44:32 +0000 (UTC) Date: Sat, 9 Apr 2016 19:44:32 +0000 From: KellerFuchs To: Bryan Ford , openpgp@ietf.org Message-ID: <20160409194243.GA20038@hashbang.sh> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 19:45:35 -0000 On Wed, Apr 06, 2016 at 04:20:08PM -0300, Bryan Ford wrote: > Getting back to DKG’s question of whether the Unix creation-timestamp should be included in the octet-stream passed to a (future) OpenPGP fingerprint scheme… I want to generalize the question into a choice between three options: > > 1. The fingerprint covers *only* the public-key material itself, in a verifiably and enforceably canonical form. > 2. [...] > 3. The fingerprint covers the public-key material and some extensible variable-length information, e.g., parameters the key-holder specifies in its self-signed cert at key creation time. > > The advantages I see to approach #1 (fingerprint covers public-key ONLY) are: (a) simplicity in specification and implementation; and (b) there may be security benefits in any public-key having one and only one fingerprint - IF canonical encoding is 100% enforced in current OpenPGP implementations, which may or may not be the case. Also, as Werner mentioned in an earlier thread, having a 1-to-1 map between pubkey and fingerprint makes it much easier to work with smartcards (or any other device) that can store the key itself, but no associated data (which seem to currently require device-specific hacks). > The advantages I see to approach #3 (fingerprint covers public-key and some extensible information) are that the key’s creator can bind to the key, at creation time, additional information that other parties might subsequently use in checking the validity or revocation status of a key, when importing or checking its fingerprint. > [...] > The general (potential) risk here - although I’m not sure how “real” it is - is that either the key-holder, or someone who manages to steal the key, can tweak the creation-timestamp and/or any other non-canonical bits that the fingerprint depends on, to create a new “public key” with a different fingerprint but the same key material as the old one. > [...] > On the upside of allowing the fingerprint to depend on non-canonical (e.g., creator-provided) information, I understand Phil is going to post a document listing some of the uses for this type of functionality, and I look forward to seeing that. But just to list a few potential uses I can think of: > > - This information could include a creation-timestamp as a Unix time, as it is now. > - This information could include a more verifiable analog to a creation-timestamp [...] A user-chosen timestamp doesn't seem to do much to help check the key's validity, and I'm not sure a verifiable timestamp helps much either (imagine I put in there an attacker-chosen timestamp, and a block which look like a verifiable timestamp, but uses a method your client doesn't support). As an aside, the Bitcoin blockchain could possibly be used as a timestamped, append-only log and thus implement your notary service (for verifiable time of creation) without using a (list of) centraly trusted service(s). > - The information covered by the fingerprint could include “hardness parameters” that feed into the fingerprint scheme itself, enabling the key creator to obtain a configurable level of protection for the key from fingerprint-mining attacks where an attacker tries to search for other keys with fingerprints that match in the first several digits. This was discussed at the last IETF meeting, and subsequently on this mailing list thread, so I won’t repeat it at length here: https://www.ietf.org/mail-archive/web/openpgp/current/msg08478.html If I understand correctly (I didn't see the subject of hashing scheme parameters discussed in the thread you linked), it would be about having parameters (iteration count, memory usage, ...) as part of the description of the prefered hashing scheme. Again, it's not obvious why it needs to be part of the hashed data, assuming the scheme parameters are displayed as part of the hash. If I can get a human to accept “Argon2(1,8): 0123456789abcdef” in place of “Argon2(1000,1000): 1023456689acbdef”, the difficulty of generating a key with such a hash [0] doesn't seem to depend on whether the parameters 1 and 8 are part of the hashed data. [0] Not the exact value 0123456789abcdef, but a “close enough” match to fool a human. On the other hand, if the human carefully compares “Argon2(1,8)” and “Argon2(1000,1000)”, having the parameters part of the hashed data doesn't change anything: I have to find a close enough match with the keyholder's “prefered parameters”. (Note that I'm not suggesting we use Argon for key hashes, but it was the first example of a scheme with “hardness parameters” that came to mind. Put PBKDF2 there, or anything else, if it makes you happier.) > - The information covered by the fingerprint could include hash-pointers to blockchain transactions in order to incorporate blockchain-randomness into the fingerprint (see https://eprint.iacr.org/2015/1015.pdf ), thereby making it extremely expensive, if not effectively impossible, for an attacker to produce another key with the same or even a similar-looking fingerprint without the attack likely being detected. Not every OpenPGP implementation would necessarily be expected to know how to actually verify this blockchain-randomness; implementations that don’t support it would just see it as an opaque blob of information that the fingerprint covers but that they otherwise don’t interpret. Even assuming the “Bitcoin blockchain shared RNG” scheme to be perfect, the “random value” is random at the time the key is generated, but from the perspective of the attacker it is a known constant that must be hashed alongside the data they control. (Worse, the attacker can choose any value that was previously output by the “Bitcoin RNG”) As such, I don't see how that makes it harder to generate a key whose fingerprint is similar to any other given key. Best, kf From nobody Sat Apr 9 16:04:10 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2412D506 for ; Sat, 9 Apr 2016 16:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG0YL2wkyxYW for ; Sat, 9 Apr 2016 16:04:08 -0700 (PDT) Received: from mail.hashbang.sh (mail.hashbang.sh [104.236.230.244]) (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 3B47712D1E1 for ; Sat, 9 Apr 2016 16:04:08 -0700 (PDT) Received: from to1.hashbang.sh (to1.hashbang.sh [104.245.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hashbang.sh (Postfix) with ESMTPS id 4F8283849; Sat, 9 Apr 2016 23:04:07 +0000 (UTC) Received: by to1.hashbang.sh (Postfix, from userid 3412) id 2E304E00BA; Sat, 9 Apr 2016 23:03:48 +0000 (UTC) Date: Sat, 9 Apr 2016 23:03:48 +0000 From: KellerFuchs To: openpgp@ietf.org, jon@callas.org Message-ID: <20160409230348.GB9034@hashbang.sh> References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> <87fuuvo4l9.fsf@alice.fifthhorseman.net> <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 23:04:09 -0000 I will avoid re-hashing points that dkg already made. On Fri, Apr 08, 2016 at 09:07:33PM -0700, Jon Callas wrote: > > > On Apr 8, 2016, at 8:15 PM, Daniel Kahn Gillmor wrote: > > > > What is the utility here, specifically? > > > > I appreciate making tracking/linkability harder as a goal, but i'm not > > conivnced that this achieves that purpose. > > PGP 3 and thus OpenPGP threw the creation time in there as a quickie salt. I didn't do it. I don't know the full reasons. > > I originally thought this was dumb. I got turned around, and believe that salting the hash is a good thing. I know that I have used this property so that I can re-use key material, but it's not the total reason. > > I can think of a bunch of half-assed things someone can do with key-canonical fingerprints if they are, say, the NSA. Nothing that's an attack, but just stuff. Given that the NSA can easily keep around a database of all public keys and fingerprints they have observed, I would like to know what is that hand-wavy “just stuff”. Moreover, what would be the purpose of reusing the same key material? > If anything, I think that salting the hash ought to be with more than the timestamp. But really, I'd keep the fingerprint computation the same, just with a more modern algorithm than SHA-1. The problem we're trying to solve is that SHA-1 is old. I like to change only one knob at a time. Which purpose does the “salt” serve here? It doesn't make it harder to find keys with a similar-looking fingerprint, at least... > Most of all, I think that semantic properties like this shouldn't change without a reason. At present, there are uses, questionable as they are, for this, and why break it just because? > > Right now, we know that for every fingerprint there is a key (modulo hash collisions), but a key can have many fingerprints. Why to we want to change it so that there's one-to-one correspondence between keys and fingerprints? This sounds to me like it's vaguely surveillance-friendly. Again, please make this explicit. Best, kf From nobody Sun Apr 10 14:15:00 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B212D157 for ; Sun, 10 Apr 2016 14:14: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnWoEeTNNW0I for ; Sun, 10 Apr 2016 14:14: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 F1F1012D124 for ; Sun, 10 Apr 2016 14:14:57 -0700 (PDT) Received: from localhost (unknown [217.13.173.17]) by mail.mugenguild.com (Postfix) with ESMTPSA id 693615FC83; Sun, 10 Apr 2016 23:14:55 +0200 (CEST) Date: Sun, 10 Apr 2016 23:14:49 +0200 From: Vincent Breitmoser To: Bryan Ford Message-ID: <20160410211449.GA12408@littlepip.fritz.box> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 21:15:00 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bryan Ford(brynosaurus@gmail.com)@Sat, Apr 09, 2016 at 12:55:42PM -0300: > - V5 =E2=80=9Ckey ID=E2=80=9D is derived from the V5 fingerprint and shor= tened for presentation > to the user - but shortened only to ~256 bits, not shortened to the point= of > insecurity like V3/V4 key IDs are. That shortening could easily include = simple > Key ID mining-protection. This was discussed before, but bringing this up again because I see you saying 256 bit fingerprint for comparison like it's the natural conclusion: It's perfectly valid to go for stronger bitsizes in algorithms with the argument that computers get better at crunching numbers all the time - but humans don't. We should not increase the bit size here just because that feels like the thing to do while revising a standard Instead, we need to carefully consider the requirements for a string used for authentication by manual comparison, the result of which I'm pretty sure will be nowhere near 32 bytes of data. - V --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXCsJJAAoJEHvRgyDerfoR60gP/3myWqVr21FOZDRFpxAxwNxZ LtigA2XSfH/lcUN6ckzax07OynOEjIjAB/KMPx2+a7t1YmLUYDwRhGxJsBzqHj+9 C4GEJx125LvCjcXSS+Spx6IlpjkKr9whb0WQM6kjhvkmv5rx+dObWqaTZZTfedTT GW+hX2y3TQicTUJTyl6Mh6bZ7jnYiFvEF4mp9r21Z+LR859PoW5ctjbhjuwez+db HcN0tRSjAghMbTozHr/2r+N2GM+mV+ze67r700Ca3bKu8GwyiKNbfvwhW3fkchdp 95rha0WimqCJoBQeXazVtjMIHDH8nPZyZvC8CsINO3DQhRQ1MEmhc8F185zbhPbk 6oORIkdKudR0Yl4p5tThfzXbG6uhT0RgztQtT+2aiJikgttq6QouegEF+47aC0AM DFLuCLJUFtQg8uJ1jZIW6am3wq0ZaSJ/LzOc/eTCyZNZ36vs16Nu6/rAScBTk/Q5 ivx1nDAXicZgsEDO1RE2bqHN9Zo4kYKxHollP/HXMEDYhT1YlIofP6BcUEIiLTgX eMV/aRccAhicGsPl/sI5XaDQzEsULdPmdBmllFP0cTgGN/a0ZF1bgN09FaYbG/ve wp11RxsyJWxA/Ijhgk8swUt/5cfvj0PEd5qltW98FRH0IyMTSQ1VucUUZ1eM+Loy X7klJ3DFt3KlXVAiyWlc =wVTJ -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From nobody Mon Apr 11 05:04:25 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A649D12EC29 for ; Mon, 11 Apr 2016 05:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyhS5ZbSZuQU for ; Mon, 11 Apr 2016 05:04:23 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 B502912EC1C for ; Mon, 11 Apr 2016 05:04:22 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id c126so153468578lfb.2 for ; Mon, 11 Apr 2016 05:04: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; bh=qCIKpw0nllaI2DZFGjwJnmtef9jUSpiS5zHOJpHBhlY=; b=M1FMRmRpsF7O3VEhKji/QKqd1gMYdyT5UHnu5QdhjPtWJ80T4B3TlwcwQHqGezzzGF INk1SSnaXQhFYKiGnfUMNW2DqFEeGgck/Kiz48o2QiWOH5IOIgHPTCHmUsicQVPVGAd/ i5GgihfEl54FH2YKZEJ3IhAAce0pdyx3IGT3f0r5ER8+zm7ZL12jgbI905HQ/60pKqmt P3cw78jo9g4LmpdhV/dUlgmn6cXgb9UX+HM7ymn2fHOS2yI5IlwgRnnnKjnCyW+3c/eg 170uNsN40Q5H+aeld+K5w0Q1sC022Ol58MjXAsesaL4yD3ecad4RnvDXlcnINxc41QDk WbGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=qCIKpw0nllaI2DZFGjwJnmtef9jUSpiS5zHOJpHBhlY=; b=ceHIrhIrMYdNCmwoaDhn74AiCBUiXwTLlvHIU7eOJU3MUSerznB6OXfzQlcO92G6Hm xK2LBkTrM6o+9jzb/NTjs+CUy+IFIiyPRhe79pzgha4GktJb5jCdbHJH/xh4rJ1vX01Y AJqPBDJdGkc9jeWsZW739pMGf2DTcOsYGwQev4EbLhf7hkH9Z9F4dq7wGp6SgoK8lyWn yh68xZkeUbDKvBszKke9PDB2tJhzesZmnRNqh6mZ31h0SPy85agFtuu7ih8uAUKpwJye PfT+oMldLVJZpmhR0ONrFJuZXaS0xk0i+4GbGDrIQw9oX3x+ffAz3dBKK7fmePELIFL5 N0kA== X-Gm-Message-State: AD7BkJInxf38Gl9jQ1RBMyQCQOjehpXJg7JIVD/QxlfjqwNsohTW1vi/3JjCcXVTMBfj+rp3pwzPJikTy+kmvQ== MIME-Version: 1.0 X-Received: by 10.112.10.109 with SMTP id h13mr6324576lbb.58.1460376260842; Mon, 11 Apr 2016 05:04:20 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Mon, 11 Apr 2016 05:04:20 -0700 (PDT) In-Reply-To: <20160410211449.GA12408@littlepip.fritz.box> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> <20160410211449.GA12408@littlepip.fritz.box> Date: Mon, 11 Apr 2016 09:04:20 -0300 X-Google-Sender-Auth: p4yFYIi8mPUeUPO-YDo5Ziq7F9Q Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:04:24 -0000 Fingerprints are used for two purposes. 1) To define a trust anchor. 2) To verify that a purported trust anchor is correct Only the first of these requires the ability to enter the fingerprint at a keyboard. The most efficient way that is compliant with existing keyboards etc. is Base32. While not all keyboards have latin characters, there is an effective limit on the number of keys, screen real estate etc. The second requires only the ability to compare the fingerprints. Here the PGP word scheme shows a more efficient approach, using an alphabet of effectively 256 glyphs that are phonetically distinct words. But we need not stop at 256 code points. We could just as easily use Base65536 or Base1048576 alphabets. Comparing pictures, words, whatever. Words are my favorite as they allow keys and/or fingerprints to be encoded in messages. Lets say that our alphabet has a restriction that the words have to be 4 letters or more. A 128 bit key in base65536 requires 8 words, lets say these are boat syringe lawnmower noise suitcase horse advice loaf. You can make up a cryptic phrase to encode the key steganographically. Fix the boat, use a syringe. The lawnmower noise is bad. etc. The downside to word dictionaries is that they are language specific. Images are better. For the Mesh, I plan to eventually use vocabularies of curated images. Get a bunch of 256 volunteers, give them the task of curating collections of 256 picture themes each to find pictures that are visually distinct. I have more here: https://datatracker.ietf.org/doc/draft-hallambaker-udf/ From nobody Mon Apr 11 05:29:37 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83412EDA0 for ; Mon, 11 Apr 2016 05:29: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYkgqB_oOn2L for ; Mon, 11 Apr 2016 05:29:33 -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 5EE9F12EDA2 for ; Mon, 11 Apr 2016 05:29:32 -0700 (PDT) Received: from localhost (unknown [217.13.173.17]) by mail.mugenguild.com (Postfix) with ESMTPSA id 5FD095FC07; Mon, 11 Apr 2016 14:29:30 +0200 (CEST) Date: Mon, 11 Apr 2016 14:29:26 +0200 From: Vincent Breitmoser To: Phillip Hallam-Baker Message-ID: <20160411122926.GA30342@littlepip.fritz.box> References: <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> <20160410211449.GA12408@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:29:35 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Phillip Hallam-Baker(phill@hallambaker.com)@Mon, Apr 11, 2016 at 09:04:20AM -0300: > The second requires only the ability to compare the fingerprints. Here > the PGP word scheme shows a more efficient approach, using an alphabet > of effectively 256 glyphs that are phonetically distinct words. I'm quite in agreement with most of your thoughts here, however the actual *representation* of this data (baseN, words, pictures, ...) was agreed to be out of scope for the standard, if I'm not mistaken. I do think though that the *length* of this data is a technical detail that should not be left up to best practices. - V --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXC5imAAoJEHvRgyDerfoR44IP/jZSwGSjm7VWNBrnH3qDwhx0 OOQQ8kGi1pLktsDAmrdw/u5XzUjHXmzYdUkzMn9Of4V7JBQVybU+5Iv9Z2y1JrUY eflrI48qvyn07fXbK9v+57QgLxSucIknS37tVtBVJamrp9Ch2TdQHIG0S4aGt/sz azR/bKU9JvFmoh9dXf8Voz3vgH/Dmt9x5tP7CN8aX9nM+CrgarX1jhpkbfRbZIUo 4KyefO4COUZ3Pw/UtduUnf9RKlNmN7sTAbDFH94vKGSiiYKjqQubyhwtjPpf5GQ8 iz0K8SpozytLeh1A1tqmLD3JJ7xU6rdO7ALtHDCaZjw0PuOE8kdoPWkBaXR8vO0F RIPzMAJe1uDhzLKbJwjhY4kIWXOM2WfdU2jU611XOSE9WId4z32MnrecCU/yj5Cw n2Q9HRbRzpGjcQftsm8BsQvBFreR1m8RKlyffg4h7OORsoPlV1gS/tsAae72BCK0 QwDCuO9mgPwUUM1WazSK03CjFLA5p5Ukp/4n2y75LuLs7GfnAJuuUkkl9yNVYNSW NEmM1PPr+h2omO+IVBsD6QLXls5C05mmN74LALw+cfFdcUNxZQ1V88PXndgkgmdu r49XA76yhPWvf4aGms+EyDpuVlpECc+mcmB55KmEcTcZGodODQSo2BDwhoEVBB+f mtC0i7Phal8Tli0PqLjp =uFNA -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From nobody Mon Apr 11 08:33:16 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7B12F098 for ; Mon, 11 Apr 2016 08:33:14 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAQZfv0MKyLq for ; Mon, 11 Apr 2016 08:33:13 -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 DEF0412F097 for ; Mon, 11 Apr 2016 08:33:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 117D8E2036; Mon, 11 Apr 2016 11:33: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 06650-05; Mon, 11 Apr 2016 11:33:03 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 65D54E2030; Mon, 11 Apr 2016 11:33:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460388782; bh=GA7bAZO5G0GyeoAW7Sj1Etqth65vzfhoXZ1dyQf9WpY=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=B3/UCv2zz6gRwdxVwkXTD60UEkOSqBlsydQNN+lVbqpx4/qARrav3XMIco021A9xs FoZs25dTCygXCMit4XQ9kbksLH6E6wjHJz3yqdfbPW9qCvvNg2AeaEWh7qhhTK7FYf S895IUpxfw8XBDMNl2oKNyvjbOxuLEZ+CZdpG2dw= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3BFWvxv021522; Mon, 11 Apr 2016 11:32:57 -0400 From: Derek Atkins To: Peter Gutmann References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Apr 2016 11:32:53 -0400 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 7 Apr 2016 11:02:50 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:33:14 -0000 Peter, Peter Gutmann writes: > Bryan Ford writes: > >>DKG brought up the question of whether that octet-string should still >>include the Unix timestamp like it currently does. > > Definitely not. What you want is a means of generating a unique lookup key > (e.g. for a database or hash table) that locates a public key. By mixing a > nonce, the timestamp, into the calculation, you lose the uniqueness, and in > fact the locatability, because the search key is no longer just a hash of the > public key but a hash of the public key and some other metadata that you may > or may not have. Other than Werner's use-case, when would you ever have the raw key paramters without the metadata and need to generate a fingerprint from it? The use cases I can imagine are: 1) You receive a signed message and want to look up the signing public key. In this case, you have the keyID/fingerprint in the signature and look it up from there. Including the timestamp is okay. 2) You receive an encrypted message and want to see if you can decrypt it. Again, in this case there is the keyID/fingerprint in the ESK packet, so you can look up the key this way. Including the timestamp is okay. 3) You have a smart card with raw key material and want to see which OpenPGP keys are there. I'm not sure I completely understand this use-case, but it's true that you don't have the metadata so cannot easily include a timestamp and use that to generate a fingerprint to lookup the public key from the raw key material. But is this a real use-case? 4) You receive a business card and want to verify the key using the fingerprint. In this case you have the fingerprint and can use it to lookup the key. *) Other use cases??? So frankly, except for #3 I don't see a use-case where you need to derive a fingerprint without already having the OpenPGP certificate. Ergo, including the timestamp (and other metadata) is Just Fine. Indeed, not including the meta data opens you up to lots of other cross-protocol issues. It means that if someone reuses the key material then you cannot differentiate the original from the subsequent certificate. E.g., if I take your certificate, extract the public key, and then create a new certificate with different timing information on it, then the fingerprints would be the same. Granted, existing signatures would not work for the new certificate, but for a lookup don't you want these to be considered unique certificates? I suppose the counter-argument is that if the metadata is included an attacker could duplicate that info, too, but then they are literally replicating your existing key. That would be like someone taking your public key certificate and adding their own userID to it. This is why we require self-signatures. > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 08:41:09 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31F812D5D7 for ; Mon, 11 Apr 2016 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnvmroIVyN2C for ; Mon, 11 Apr 2016 08:41:06 -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 3350F12DC3E for ; Mon, 11 Apr 2016 08:41:06 -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=1460389266; x=1491925266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Oz/fBFtPhzvfLDzyj+Mn2pEZ2vzZCN60ypMhSIxR4FY=; b=SPDve1vg9Z88RLfgoCdMZJuHg349D3tamB6k75SByskKamAoJJ25cezi mTUI6GYGNGivJ1Cg4wtZKbittvhUpSzFIRa3k7vvApkHvEe2mGJKFw0xZ KzBZsQptPhc0L2tL0LxtS/XrxMxQtDfghoQ8+wuXU7b6CUnt0f99l3I6y AjuAt0lWOAnBFZwcBZU8+7po7w3zJDeqEup5Dbh2qIMgwHDEowxNdm77K d1JpXados3EiWhk96Co87D6aqriKZglxQEmcOGOv1hNKl58xFfJ2H/U3g YELpec3UlunEYBO/CF1T/xE8BU9ydvmGlSdZU09fBZBKLjDxysFk4JkkP A==; X-IronPort-AV: E=Sophos;i="5.24,462,1454929200"; d="scan'208";a="79423852" 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/AES256-SHA; 12 Apr 2016 03:41:04 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 12 Apr 2016 03:41:03 +1200 From: Peter Gutmann To: Derek Atkins Thread-Topic: [openpgp] Fingerprint schemes versus what to fingerprint Thread-Index: AQHRlAd4MKBUzg/A2UeXohEtWdfl5p+E6Nhw Date: Mon, 11 Apr 2016 15:41:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, 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: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:41:07 -0000 Derek Atkins writes:=0A= =0A= >3) You have a smart card with raw key material and want to see which=0A= > OpenPGP keys are there. =0A= =0A= That's PKCS #11, which means pretty much all crypto hardware that uses a=0A= standardised interface.=0A= =0A= >*) Other use cases???=0A= =0A= You have keys stored in a non-PGP format. It makes keys from anywhere else= =0A= pretty much unusable for PGP because you can't look them up.=0A= =0A= >It means that if someone reuses the key material then you cannot=0A= >differentiate the original from the subsequent certificate.=0A= =0A= That assumes you re-use the same key over and over, rather than just=0A= generating a fresh key when you need one. That's X.509 practice, not PGP.= =0A= =0A= Peter.= From nobody Mon Apr 11 08:45:47 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19412D901 for ; Mon, 11 Apr 2016 08:45:46 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOCYE7Qz-KLj for ; Mon, 11 Apr 2016 08:45:45 -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 5392712D98B for ; Mon, 11 Apr 2016 08:45:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DFFEDE2036; Mon, 11 Apr 2016 11:45:42 -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 06826-05; Mon, 11 Apr 2016 11:45:35 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 B2FB4E2030; Mon, 11 Apr 2016 11:45:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460389535; bh=wl7X1I7A9m8WyFsgg38W8zh6aWuX3GweHb8MHYCCmkg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=GewUW7zvJkk4TbxZObDNpKtCGyImVcx/bfRmH8C4doy8tBCGTuZMMlDodpXveAJaj aRBwcShmrOnqAnSJ1UyJia1TA84PP/JYB0T3dgeQfFv0msoAqxYitT96rI82U4JXD6 HWF5ZityWcnhQluzJ4x5zspimN1C7AEcUHAkjnvg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3BFhVOI022145; Mon, 11 Apr 2016 11:43:31 -0400 From: Derek Atkins To: Jon Callas References: <5CA36ED3-92DB-4E93-A685-89011D0E0B24@callas.org> <0DBED279-2F24-4330-90C9-F79FE4893657@gmail.com> <8F744860-B361-41C2-9AC1-954E42CAFEDF@callas.org> <87fuuvo4l9.fsf@alice.fifthhorseman.net> <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> Date: Mon, 11 Apr 2016 11:42:58 -0400 In-Reply-To: <3E66B089-8D26-42EE-998D-5C2B6340131C@callas.org> (Jon Callas's message of "Fri, 8 Apr 2016 21:07:33 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Should fingerprints be "key-canonical"? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:45:47 -0000 Jon Callas writes: >> On Apr 8, 2016, at 8:15 PM, Daniel Kahn Gillmor wrote: >> >> On Thu 2016-04-07 20:33:56 -0300, Jon Callas wrote: >>> Yes, because I can tell you that it's *really* useful to be able to >>> reuse the key material from alice@example.com for (e.g.) >>> jobs@example.com or security, or whatever. I've done it a lot over >>> the years. >> >> What is the utility here, specifically? >> >> I appreciate making tracking/linkability harder as a goal, but i'm not >> conivnced that this achieves that purpose. > > Let me rewind then. PGP 2 had key-canonical fingerprints. There were > issues with them. Nothing particularly horrible, but they we all of > the sort of fun and games that you can play with the emergent > properties of hash functions. And really, I can't remember them all > that well because that was ages ago. > > PGP 3 and thus OpenPGP threw the creation time in there as a quickie > salt. I didn't do it. I don't know the full reasons. It threw in both creation time AND the (optional) expiration time! Please don't forget the expiration time! Unfortunately that was removed in v4 (but I don't remember why). > I originally thought this was dumb. I got turned around, and believe > that salting the hash is a good thing. I know that I have used this > property so that I can re-use key material, but it's not the total > reason. > > I can think of a bunch of half-assed things someone can do with > key-canonical fingerprints if they are, say, the NSA. Nothing that's > an attack, but just stuff. > > If anything, I think that salting the hash ought to be with more than > the timestamp. But really, I'd keep the fingerprint computation the > same, just with a more modern algorithm than SHA-1. The problem we're > trying to solve is that SHA-1 is old. I like to change only one knob > at a time. > > Most of all, I think that semantic properties like this shouldn't > change without a reason. At present, there are uses, questionable as > they are, for this, and why break it just because? > > Right now, we know that for every fingerprint there is a key (modulo > hash collisions), but a key can have many fingerprints. Why to we want > to change it so that there's one-to-one correspondence between keys > and fingerprints? This sounds to me like it's vaguely > surveillance-friendly. > > >> >> Anyone who has the keys for alice@example.com and jobs@example.com can >> tell that these are the same keys, and can just join them in their >> linkability/trackability database. >> >> Furthermore, it introduces additional management problems for Alice; if >> she loses control of the secret key material, she now has to ensure that >> she's generated a revocation certificate for each "flavor" of it, >> because the revocations are bound to the same material that the >> fingerprint is bound to. > > So? The reason to break the binding between key material and a > certificate is so that there's no binding. > > Actually -- this sounds like as much a reason to salt it. There are > more reasons to revoke than loss of key material, and this means that > revocation is even less useful. > > Jon -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 09:11:05 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4145012DF25 for ; Mon, 11 Apr 2016 09:11:04 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfchqLu1XK2Q for ; Mon, 11 Apr 2016 09:11:02 -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 4F8CE12DA67 for ; Mon, 11 Apr 2016 09:11:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 59938E2038; Mon, 11 Apr 2016 12:10:59 -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 06921-06; Mon, 11 Apr 2016 12:10:53 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 399E5E2030; Mon, 11 Apr 2016 12:10:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460391053; bh=3Z5B19iVwGVOOfRC+BOIMyl2iS7mS5EbBPCxO4fPKZ8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=hCdUXzUkAsqSDvKDGJxXkgl61tgh7hnEoVnTgqlAkxNLPfKzKbMsPuKEzM/iLWJ0d ydxaBJ9A37M0+aCh9JTjY8J9Yk2M4Cr8fYBnUawK2IotRLkisjOpjfZFJ1yMXEo5D7 sgxSmpfmPM9UrBawk9COdrthhUjjq0rr+pwIfbss= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3BGAlYX023771; Mon, 11 Apr 2016 12:10:47 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <9A043F3CF02CD34C8E74AC1594475C73F4C46D17@uxcn10-5.UoA.auckland.ac.nz> <20160408215053.GA191287@vauxhall.crustytoothpaste.net> <874mbbqzjt.fsf@alice.fifthhorseman.net> <87egafkt6d.fsf@wheatstone.g10code.de> Date: Mon, 11 Apr 2016 12:10:45 -0400 In-Reply-To: <87egafkt6d.fsf@wheatstone.g10code.de> (Werner Koch's message of "Sat, 09 Apr 2016 11:50:02 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" , "brian m. carlson" Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 16:11:04 -0000 Werner Koch writes: > On Sat, 9 Apr 2016 04:35, dkg@fifthhorseman.net said: > >> (and there's no reason that OpenKeychain needs to use the fingerprint -- >> for Ed25519 keys, they could just put the public key itself in the QR > > Which would also encourage not to add a salt (creation timestamp) so > that there is no need to somehow also convey the creation timestamp. Wait, is this for the authentication string or the DB lookup handle? I still think we're conflating the two. And for an authentication string I including the additional data is just fine. When someone hands me the business card I would expect it to contain the authentication string, not the DB Handle. But there is also additional data available to me, like the userID (email address). >From a user process point of view I would expect to lookup the key using the userid and then use the authentication string from the business card to make sure I got the right key. At this point, including the metadata (timestamp) in the authentication string is fine, because I have the public key certificate including all the metadata. If you're doing automated key transfer then you could just use the Database Lookup Handle. But again, at that point where you have the handle and need to look up the key, the only question is whether you have a database or just raw material. > Shalom-Salam, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 09:21:50 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1560612F0E1 for ; Mon, 11 Apr 2016 09:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2bYpoK1P6CN for ; Mon, 11 Apr 2016 09:21:47 -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 11E8212F0E0 for ; Mon, 11 Apr 2016 09:21:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CFBCDE2030; Mon, 11 Apr 2016 12:21:44 -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 07058-05; Mon, 11 Apr 2016 12:21:39 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id D4616E2038; Mon, 11 Apr 2016 12:21:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460391699; bh=eOmURMPpSkXkUiGC8VKo/zi/p6nzifHtX0hSwqn59uQ=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=JKaMLDQ9Q4xjMj+BxknvCXdTUHyU/XkLg8COufmbCpmMVmJ3G2AtM5I9f/VFb0b+O vGGRcFtbl8UME0HFNoEcyvz8PaM7p+2c/T8y3S00VDzNd5TBrJnWhbtOtdL73ZfMMu G+6mX9LQye2ZC8Lhy0GYHlEnxDq5ODHTMEMnpN90= Received: from 24.54.172.229 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 11 Apr 2016 12:21:39 -0400 Message-ID: <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Apr 2016 12:21:39 -0400 From: "Derek Atkins" To: "Peter Gutmann" 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: "openpgp@ietf.org" , Derek Atkins , Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 16:21:48 -0000 Hi, On Mon, April 11, 2016 11:41 am, Peter Gutmann wrote: > Derek Atkins writes: > >>3) You have a smart card with raw key material and want to see which >> OpenPGP keys are there. > > That's PKCS #11, which means pretty much all crypto hardware that uses a > standardised interface. Are you expecting this would work in a vacuum? I.e., would you expect that you can take your OpenPGP smart card to a fresh system on which you've never used OpenPGP ever and be able to plug in that smart card and have it be able to sign a document? If the answer is "no", then you're fine. You can have private key lookup metadata on the OpenPGP system online that gives you the handle to the PKCS11 key. If the answer is "yes", then the follow up question is whether there are additional data available (e.g. storing associated public keys/certs) that you could use to provide the additional metadata. But I only see this being an issue where you want to make a signature (which needs to know your keyID) using a smartcard on a system that does not contain any additional metadata. Is this a real use case? >>*) Other use cases??? > > You have keys stored in a non-PGP format. It makes keys from anywhere > else > pretty much unusable for PGP because you can't look them up. It depends. If I've got an X509 cert I can convert that to an OpenPGP cert, and all the appropriate metadata is there. I admit I'm not familiar enough with PKCS12 to know what data is included there, or whether there is enough information in an X509 private key data file to stand on its own. >>It means that if someone reuses the key material then you cannot >>differentiate the original from the subsequent certificate. > > That assumes you re-use the same key over and over, rather than just > generating a fresh key when you need one. That's X.509 practice, not PGP. > > Peter. Yes, it does assume that. This goes back to my arguments that we should include expiration time in the key identifier/fingerprint so that there is a hard expiration. In order to change that you could copy the key material but it would necessarily be a new "key" (certificate) because changing the expiration would change the keyID/fingerprint. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 12:21:57 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BDC12E821 for ; Mon, 11 Apr 2016 12:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLLAk_Hkir_8 for ; Mon, 11 Apr 2016 12:21:52 -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 C45F212E6A5 for ; Mon, 11 Apr 2016 12:21:51 -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=1460402512; x=1491938512; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qN4zJjAHfWQZAEKbHE3V9+1HN0mq2ed32MnUS1EMg34=; b=splOWc+BlINuAXdmZ/KnZXozAmBExgmIXV9FewFEvGMCsrLXV5f6Acv5 xZ/WXFymJAdRiV2A//PFK3QGUSniEdrFaLuYd8O2gbZQKmJI2mP/TkWud oyFOaZF6yrzF0+bpDu95mHLcoZPcRQuc30BpoKSbLnDaxJORPwctWjmIP f0KBzeaxf82Uht4zlERnfYAdAhjd2GH6J9ufL5bafQphn+k4ZFZwRg8Uz tUvf0YBnfKtDHlzaXAzFIMO39jjbuVVGqk0JecRqHyOYUPDCqoaBTlw2j 9vFuZVdyDzA9mp0eZXIgmEy8xqtI8Oy1Ge/DsUNd6cQSvvWd8c3ELPcoT A==; X-IronPort-AV: E=Sophos;i="5.24,469,1454929200"; d="scan'208";a="79440550" 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/AES256-SHA; 12 Apr 2016 07:21:49 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 12 Apr 2016 07:21:50 +1200 From: Peter Gutmann To: Derek Atkins Thread-Topic: [FORGED] RE: [openpgp] Fingerprint schemes versus what to fingerprint Thread-Index: AQHRlAd4MKBUzg/A2UeXohEtWdfl5p+E6Nhw//9CYoCAAPtXPw== Date: Mon, 11 Apr 2016 19:21:49 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> In-Reply-To: <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] [FORGED] RE: Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 19:21:56 -0000 Derek Atkins writes:=0A= =0A= >Are you expecting this would work in a vacuum? I.e., would you expect tha= t=0A= >you can take your OpenPGP smart card to a fresh system on which you've nev= er=0A= >used OpenPGP ever and be able to plug in that smart card and have it be ab= le=0A= >to sign a document?=0A= =0A= I'm not sure what OpenPGP cards have to do with this, since I'm talking abo= ut=0A= PKCS #11. I can use a PKCS #11 device with X.509, with S/MIME, with TLS, w= ith=0A= SSH, with IKE, and quite probably with a number of other, lesser-known=0A= Internet security protocols. The one significant one I can't use it with i= s=0A= PGP.=0A= =0A= >Is this a real use case?=0A= =0A= Yes, see above.=0A= =0A= >It depends. If I've got an X509 cert I can convert that to an OpenPGP cer= t,=0A= >and all the appropriate metadata is there.=0A= =0A= You still can't use it with PKCS #11.=0A= =0A= Peter.= From nobody Mon Apr 11 12:31:04 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3860312DE3F for ; Mon, 11 Apr 2016 12:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfQh0PCcMaqb for ; Mon, 11 Apr 2016 12:31:01 -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 B546A12D9FA for ; Mon, 11 Apr 2016 12:31:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8910CE2036; Mon, 11 Apr 2016 15:30:54 -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 08318-05; Mon, 11 Apr 2016 15:30:46 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 82458E203F; Mon, 11 Apr 2016 15:30:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460403043; bh=m2HbVeEIvG86uLRMNgVBLyfbg3IfJZkV+NlLDZI+5xY=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=EUkKe37WiaFCSdlHbPE11/DsGTTO3LUztz0y3o+KCLIGEFXFMzFsiyqaTfNosd0oB nnFSxuCDDGH/7nsmjo5R/613+jplOkN7esAtDE7JJGe7NGVxK+JZ1JiJ8GntYD8P0S n5gPjGRzKWzTHhmVEYojkZPuRIuNSzKZ/TFf3TCs= Received: from 24.54.172.229 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 11 Apr 2016 15:30:43 -0400 Message-ID: <1025d76f337d2f2fe8a11d7626b11158.squirrel@mail2.ihtfp.org> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Apr 2016 15:30:43 -0400 From: "Derek Atkins" To: "Peter Gutmann" 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: "openpgp@ietf.org" , Derek Atkins , Bryan Ford Subject: Re: [openpgp] [FORGED] RE: Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 19:31:03 -0000 Paul, On Mon, April 11, 2016 3:21 pm, Peter Gutmann wrote: > Derek Atkins writes: > >>Are you expecting this would work in a vacuum? I.e., would you expect >> that >>you can take your OpenPGP smart card to a fresh system on which you've >> never >>used OpenPGP ever and be able to plug in that smart card and have it be >> able >>to sign a document? > > I'm not sure what OpenPGP cards have to do with this, since I'm talking > about > PKCS #11. I can use a PKCS #11 device with X.509, with S/MIME, with TLS, > with > SSH, with IKE, and quite probably with a number of other, lesser-known > Internet security protocols. The one significant one I can't use it with > is > PGP. Sorry, by "OpenPGP Card" I mean "a smart card to use with OpenPGP". You can absolutely use PKCS#11 with PGP; there are plenty of instances today where that is the case. You just need an implementation where the secring.skr file contains the reference handle to your smartcard key materials. More specifically: when you have your card generate your key material, you pull off the public key and then generate your public key, compute your fingerprint data (including OpenPGP metadata), and also create secring data that contains whatever PKCS#11 reference data you need to re-access that key. Later when you use that card/key you know how to reference it. So what exactly is the issue? >>Is this a real use case? > > Yes, see above. > >>It depends. If I've got an X509 cert I can convert that to an OpenPGP >> cert, >>and all the appropriate metadata is there. > > You still can't use it with PKCS #11. Sure you can. > > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 12:42:40 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199C912D876 for ; Mon, 11 Apr 2016 12:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeZh1RIZvttF for ; Mon, 11 Apr 2016 12:42: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 5E7E012D754 for ; Mon, 11 Apr 2016 12:42: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=1460403756; x=1491939756; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qZJpNGtl9Dg8xcpCUcEnwxM/bzFwFB6guF8Y5Cat0uI=; b=tD3iKV3PML/6wnko57s5KfmaR2jBfX+r/SiHP35Z7w55T9PTE2bId68j gGP8JLOmaApChwKBQ+yoysW20FWz2OFZde9aSISQqxeaqf4qyNhFmw72P U/73pNNNx5CuZ/Rkc9A28EbLjcO34JsJIdtgIPoAGwS3r+7wruDOEQGDj TNk56LqSwZ0n3gwZDjU2HZrqPSY4feF1fC+NeAaAfZ8BW7xYQM5414PqQ 9cqPI6PY73xiFaM0bkenYMtLD2QpDjeBZ4iSuAfajDNy0qwLTlBxPhhgT PJFilKgEl3qOIC8JgoLX2ZZXGQYnlg4Pd/8qUkAjj1X2QAN/m0Cab0vOs A==; X-IronPort-AV: E=Sophos;i="5.24,469,1454929200"; d="scan'208";a="79442557" 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/AES256-SHA; 12 Apr 2016 07:42:35 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 12 Apr 2016 07:42:34 +1200 From: Peter Gutmann To: Derek Atkins Thread-Topic: [FORGED] RE: [FORGED] RE: [openpgp] Fingerprint schemes versus what to fingerprint Thread-Index: AQHRlAd4MKBUzg/A2UeXohEtWdfl5p+E6Nhw//9CYoCAAPtXP///OXyAgADMS9g= Date: Mon, 11 Apr 2016 19:42:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C57DFB@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz>, <1025d76f337d2f2fe8a11d7626b11158.squirrel@mail2.ihtfp.org> In-Reply-To: <1025d76f337d2f2fe8a11d7626b11158.squirrel@mail2.ihtfp.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] [FORGED] RE: [FORGED] RE: Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 19:42:39 -0000 Derek Atkins writes:=0A= =0A= >More specifically: when you have your card generate your key material, yo= u=0A= >pull off the public key and then generate your public key, compute your=0A= >fingerprint data (including OpenPGP metadata), and also create secring dat= a=0A= >that contains whatever PKCS#11 reference data you need to re-access that k= ey.=0A= >Later when you use that card/key you know how to reference it.=0A= =0A= Where do you store all this stuff? PKCS #11 doesn't provide a means of=0A= storing it, you can search by something like the public key or=0A= issuerAndSerialNumber, but not by hash-of-the-public-key-and-nonce.=0A= =0A= Peter.= From nobody Mon Apr 11 12:51:40 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B53212DA69 for ; Mon, 11 Apr 2016 12:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVvgK9sw2znp for ; Mon, 11 Apr 2016 12:51:37 -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 6F55A12D911 for ; Mon, 11 Apr 2016 12:51:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 439F5E2036; Mon, 11 Apr 2016 15:51:04 -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 08469-06; Mon, 11 Apr 2016 15:50:58 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 5D107E2044; Mon, 11 Apr 2016 15:50:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460404257; bh=S/lXesTFVl8Wj1xAWdMiz/HzSMvKGr8DcBkv9p1vSpU=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=FOzppIh8DRD2VxcPd2kLPE4NeW6zSAy7Hx0rmG3fkhy1wLR457A9nD9MAswTiCdhs 0hnUNo8ElZndXGA6SMUfyd9QnHrUZTAE5hkEgUaSNle/+valLUCc3L3NAG7zK5sJlz x8SiYUb3NfM3SUm+U9LUyGAS0k52FTD8Ow86HKdU= Received: from 24.54.172.229 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 11 Apr 2016 15:50:56 -0400 Message-ID: <001f8b61900c9516081eed6ee177bde7.squirrel@mail2.ihtfp.org> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C57DFB@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz>, <1025d76f337d2f2fe8a11d7626b11158.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DFB@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Apr 2016 15:50:56 -0400 From: "Derek Atkins" To: "Peter Gutmann" 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: "openpgp@ietf.org" , Derek Atkins , Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 19:51:38 -0000 Hi, On Mon, April 11, 2016 3:42 pm, Peter Gutmann wrote: > Derek Atkins writes: > >>More specifically: when you have your card generate your key material, >> you >>pull off the public key and then generate your public key, compute your >>fingerprint data (including OpenPGP metadata), and also create secring >> data >>that contains whatever PKCS#11 reference data you need to re-access that >> key. >>Later when you use that card/key you know how to reference it. > > Where do you store all this stuff? PKCS #11 doesn't provide a means of > storing it, you can search by something like the public key or > issuerAndSerialNumber, but not by hash-of-the-public-key-and-nonce. Like I said, you put it into your secring.skr file. > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 13:01:00 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03A12D621 for ; Mon, 11 Apr 2016 13:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNMmvSvmsqAt for ; Mon, 11 Apr 2016 13:00:56 -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 2048512D72F for ; Mon, 11 Apr 2016 13:00:54 -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=1460404855; x=1491940855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HINGkWCd4Zz5LSqkPHvH2lOcwTEDKnbrZjZyef0GTeU=; b=rwDFGBfiFFe6Ss2d56KKBoKAG9Ae4rtEBi01aJvmsDGc4XDGm81+UTe8 rJuFypjzgmtExFgBp1ThicJAi2//cre+Z6WM4hFzv1Ocrbn+dpdRZ6Eqv 5DTTTchPYhi7eIx/ogS2nCY79hXFIzQkfmAw2FaXECN2VSIsnFDOypBzR e7wRWRuo38bfuqodfrGG4WWk3lrrHkjG4ChY3I9koTkXRlaGPod8xzgnB S+q11uvfxPYA6lchZcfwA8fS93hkEoAAwnVDqFtAXXB4eKoMg8oavyfph Cysbg0ozKxF/Ln9T4dlGpgBB6frA/1RxNBNUGj5moARTTBigbLK9jOVCS w==; X-IronPort-AV: E=Sophos;i="5.24,470,1454929200"; d="scan'208";a="79444460" 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/AES256-SHA; 12 Apr 2016 08:00:53 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.33]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Tue, 12 Apr 2016 08:00:52 +1200 From: Peter Gutmann To: Derek Atkins Thread-Topic: [FORGED] RE: [openpgp] Fingerprint schemes versus what to fingerprint Thread-Index: AQHRlCt+rZao6ETIzE+Sd0pvvJC4lp+FMSDT Date: Mon, 11 Apr 2016 20:00:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C57E39@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz>, <1025d76f337d2f2fe8a11d7626b11158.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DFB@uxcn10-5.UoA.auckland.ac.nz>, <001f8b61900c9516081eed6ee177bde7.squirrel@mail2.ihtfp.org> In-Reply-To: <001f8b61900c9516081eed6ee177bde7.squirrel@mail2.ihtfp.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] [FORGED] RE: Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:00:58 -0000 Derek Atkins writes:=0A= >On Mon, April 11, 2016 3:42 pm, Peter Gutmann wrote:=0A= >> Derek Atkins writes:=0A= >>>More specifically: when you have your card generate your key material, = you=0A= >>>pull off the public key and then generate your public key, compute your= =0A= >>>fingerprint data (including OpenPGP metadata), and also create secring d= ata=0A= >>>that contains whatever PKCS#11 reference data you need to re-access that= key.=0A= >>>Later when you use that card/key you know how to reference it.=0A= >>=0A= >> Where do you store all this stuff? PKCS #11 doesn't provide a means of= =0A= >> storing it, you can search by something like the public key or=0A= >> issuerAndSerialNumber, but not by hash-of-the-public-key-and-nonce.=0A= >=0A= >Like I said, you put it into your secring.skr file.=0A= =0A= But you can't store a secring.skr file on a PKCS #11 device. Or are you=0A= expecting the user to carry around a smart card and a separate USB key with= =0A= all the stuff that can't be stored on the smart card, with an app that know= s=0A= how to combine all the bits and pieces together to make use of it?=0A= =0A= Peter.= From nobody Mon Apr 11 13:08:01 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270C312EFC4 for ; Mon, 11 Apr 2016 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3bdlfihqOmk for ; Mon, 11 Apr 2016 13:07: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 CEF0D12EFC8 for ; Mon, 11 Apr 2016 13:07:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C1ED9E2038; Mon, 11 Apr 2016 16:07:52 -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 08611-06; Mon, 11 Apr 2016 16:07:47 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id B6D1CE2036; Mon, 11 Apr 2016 16:07:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460405267; bh=1Xiq1qjvT/J2z2PQHimp5Cm1ATzflsYR/CGjlsBGK2k=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=UoB0jJqEadz9kTWwVHwieixwbLUHwGxEBqe2zRDmdmCDr4H8wCTqIqc6CWHynSwl8 vaprwG4RI+M7BUfT2C3PFBgXhykf+sGGkyI5j74+F18tuYJQVYRYUaOYoGpDiMLwoc SMtsAKnSyYESUvc6rtpIv4Tp/ChPXQ5Qi2BBC1pc= Received: from 24.54.172.229 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 11 Apr 2016 16:07:47 -0400 Message-ID: In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C57E39@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz>, <1025d76f337d2f2fe8a11d7626b11158.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DFB@uxcn10-5.UoA.auckland.ac.nz>, <001f8b61900c9516081eed6ee177bde7.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57E39@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Apr 2016 16:07:47 -0400 From: "Derek Atkins" To: "Peter Gutmann" 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: "openpgp@ietf.org" , Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:07:59 -0000 On Mon, April 11, 2016 4:00 pm, Peter Gutmann wrote: > Derek Atkins writes: >>On Mon, April 11, 2016 3:42 pm, Peter Gutmann wrote: >>> Derek Atkins writes: >>>>More specifically: when you have your card generate your key material, >>>> you >>>>pull off the public key and then generate your public key, compute your >>>>fingerprint data (including OpenPGP metadata), and also create secring >>>> data >>>>that contains whatever PKCS#11 reference data you need to re-access >>>> that key. >>>>Later when you use that card/key you know how to reference it. >>> >>> Where do you store all this stuff? PKCS #11 doesn't provide a means of >>> storing it, you can search by something like the public key or >>> issuerAndSerialNumber, but not by hash-of-the-public-key-and-nonce. >> >>Like I said, you put it into your secring.skr file. > > But you can't store a secring.skr file on a PKCS #11 device. Or are you > expecting the user to carry around a smart card and a separate USB key > with > all the stuff that can't be stored on the smart card, with an app that > knows > how to combine all the bits and pieces together to make use of it? Okay, now I feel like we're going around in circles. In my VERY FIRST message I asked whether you are expecting the user to make a signature on a system that has never used or seen their key material before? By your lack of answer to that very specific question I went ahead with a workable architecture where, yes, there are data files that need to be carried along with the smartcard. The smartcard is the "protected" data, but there are other data that need to be carried along, too. Maybe this isn't as "pure" as using PKCS#11 for X509. But it certainly is a workable (and working) solution. > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 11 16:28:46 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791DB12F64D for ; Mon, 11 Apr 2016 16:28:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwVzPiL-hVfv for ; Mon, 11 Apr 2016 16:28:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A5612F64C for ; Mon, 11 Apr 2016 16:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oMX8K+oiPt0xDRhqCgbMcPFPmb0QLk9PtvhDrpPrMlg=; b=bu60nnQhDYW65RHlE2Y3KtH9SuQqdgwnjOa9iRafCKplfhA0KVOL7Aif1EVQehKz5ae3QfGhHsqxpqjM6PA1S6PWICKC7E9DxUU/vO/fXPpWEfGDH9rVubLUT7LtP3ubPYrbRIaI/KVLj24IGDsTqEZHIT2mPCQf9zONw6/Vff4= Received: from SN1PR0501CA0017.namprd05.prod.outlook.com (10.163.126.155) by BLUPR0501MB802.namprd05.prod.outlook.com (10.141.251.140) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 23:28:21 +0000 Received: from BY2FFO11OLC004.protection.gbl (2a01:111:f400:7c0c::162) by SN1PR0501CA0017.outlook.office365.com (2a01:111:e400:52fe::27) with Microsoft SMTP Server (TLS) id 15.1.453.26 via Frontend Transport; Mon, 11 Apr 2016 23:28:20 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BY2FFO11OLC004.mail.protection.outlook.com (10.1.15.184) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Mon, 11 Apr 2016 23:28:20 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 11 Apr 2016 16:28:20 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u3BNSJA48359; Mon, 11 Apr 2016 16:28:19 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 89D3911542; Mon, 11 Apr 2016 16:28:18 -0700 (PDT) To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz>, <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Mon, 11 Apr 2016 19:21:49 -0000." From: "Mark D. Baushke" Date: Mon, 11 Apr 2016 16:28:18 -0700 Message-ID: <87608.1460417298@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(87936001)(117636001)(5003940100001)(586003)(86362001)(47776003)(76506005)(106466001)(53416004)(105596002)(54356999)(11100500001)(76176999)(50986999)(93886004)(110136002)(15975445007)(189998001)(5003600100002)(2906002)(77096005)(50466002)(81166005)(6806005)(2810700001)(48376002)(2950100001)(19580395003)(19580405001)(4326007)(92566002)(1096002)(1220700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB802; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC004; 1:0dRw4LTI50IAoI5JXHqNmPqTpczK7BVMOvTYlm8ZDMI5OC3P1LC81OF2MwlOFtbnqZWbIVrQyXhmsFSTiBEOXIWeS6KjMlIaS8TDqgdt6U5G8F9xfwDg5hVp6vpZFI3yOzZZDrv62ufykL0PxGP4mLjyxi+6+lhB3dWgP63iUdi+T6i11YAlY4mE8mVa3LTX4r9CePRR0GvXELTO7TaBH/qzWgRHTlzeHL28wsQGjtK3Vdu9pLuXGC1F8re5RWELCnir/kZjLK9299c+SDc/EgGs+C+ZIbLza6oO/C5pbqc3LKgGheeSqJXqpyL0u0S6nDkdaRdN2Ujloe0L1QrZrh5c4bwzVNa3w27t/pTskctqConc0pD7r8236vSeGldZIG73VcnhWcM0cVvErL6gf5EHqE6sRJcpt3xYXAuesVzRcWpB5zgTLTBHEtiHWVXwnlsfCCbg4qxnGzOK1giUAOpLTYkm/DV44uiWwbpIBghbHkb+Ltf7dt8hY95rOqGer6Iy61zCO7J1SXzB+hcOIUKq7q4aEzS/zJXcVwO2oXQ= X-MS-Office365-Filtering-Correlation-Id: 793ded0b-af7d-4f3e-6415-08d36260f840 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB802; 2:yJ4zi1hF13By/d+CELe3cbZsKUmHlktJb1C7LMxUmtyEMWvDhKIsMcsaax2Kqjlf5GJpMaBOfjJ+4QA1Q+4mTXrTpuzNZLrQ/38mQVCjrZNdxh50QwabQYocXhte2NzZv6Vh8gW0+xf9i0UJlwoZwxDEHn7fMAEIBp/LTkbNNRS2tREgx1KX6rbULkXFRz58; 3:TQXCUVwwgrXswX3AefsYhdm+Li1l+RleafmHGNQdQopaYN8RX/+0vAHxtsRzckUallFJRVd9cbh1nqljBivuZwYMz9lHUcfKxtWjJheKLAof3eeey2dq/dMa1zC3z1GUlnV1ixq7doTumTg3IaTg7KNRfuzVMS6mjxB54Z6AgkIA9rcW5hBA71QS8f5oW7tLhWoSeOPr4dB6kCr8MaK2NeF10UNpgnrAGnqIu6OJ6jQ=; 25:gg94FlqinD+sNXTOH9rXMFp2cOeoZI1kEcOGJw5eNNOzauzoCuVEcAgt9ZLZRlQ7qBshOR3skGFXsKwfCBtCtcNiOOMZYPvTj3qn/Onj/VhQJtRWljrk6dU6GJMNv7ziLtee65XBwmX18I/fIkUq/LJoURKzTWPgyOlzNodVg63ldQLY8usEdWLvWx74t+fmaT7hUVvvCPVCIFCsVPcOvUTxc8hOR5+mOfEn54BmyDrEVZdqAu7Hfdoyn878LXxAKUYuM/dqHKAujKkcc0tALRf/tPU5A3o4mdycpn7Jp+FOvGr8NugpZErzylMVEn6YvjT4tW9++lb12/L+h346Ug== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB802; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB802; 20:iTMro9mFkxJSgS83R+B5NXdJSuCHecHilwEwCpPdBuqhCbP4aIy30UEAsHzmbpILsoIfJ+7vXKudby+hT3cN0NdhxRA1csM/YXaqJ+qD8kUynPrJfcLro//kPU9evDUEgjfTbuVwGSulTGtdsvIbfCpGOoWIq+1zihluLfNeb28zaMiqXdZ2sKDvg29bXVzhkqe+FgkFofBf5vk9x9at+rwqSOnDIBd8y7PQrI9wFFiVJmycc4WminBVXf0fV+An04sZMIfAoK7LlngbMcvszfFXRcWUpc2w0kn/ETFKYgx3sbqDx+AgnyAhAxaLdmvxLvnyp4Xi7sUa/vosf8ouNGfB0++FP1+u/2TS2mjeu5Q6dGBSJdHNZsEAP+Gk+msQs7z1f/UsEczOV0hzwbSXLgEDbTK67y4VWRFPhiWM9cgd+rsSIJFnc6RNtJN10S/BwU+WAqpqg4V4Rf4qSVMze0nBb8tWjbZh8ZgtcNbr2gm7/JCJwDOJArQwA8aEt+xC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(13024025)(13023025)(8121501046)(13015025)(13017025)(13018025)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB802; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB802; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB802; 4:poF2cgzb4PYIIZg4HIUbtMui6o3/PAVKTYJuEegvL7EtCvFnkjo055RdCxVOKnk/tf1QOTnCx12+IRo3BpJVdwcgQE+D8lg/LraMhQRkqU51iuxtd1oP8/5nKigbfQus3OdTPdUQpQZg51oQhdNFIlR1ALeGs14g8M9PaSrve0uJT+xRVJ4RLVxHFfJjaCUtnJZZHs/jVXKXJtyrY+XTYUEyCA5nBFnn78NwAU9qCj6KZbvw8dk5/tTHbJTxMpqEUERUU5FRfVsJZrmNrK04sPglI/GDd6BUUiMoav5Nm3JPOaKC8yTUddtfMCOEQUdFPG1FQGaSnapl3hKsnJtcldAmhDhxhi8DOxUO/oKGHmaOlXWzqRqXjT9iQakq2kV1g38eVvoddaOyCCusvOZuPntaAnm7iHC3s2EgdviRq5wwwOwOKff0hjHRQMrowWBvQ7IFe9pSyeIep8b417wVuHym9lMTsSHj8lKcKq61uZM= X-Forefront-PRVS: 09090B6B69 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB802; 23:nh90XSg1AKmGdCGKyfxubc5R2Oep5SAbA4yvAqAJ?= =?us-ascii?Q?JElWiEdVr6CPcgNWu7GRpyTyvhRIvvakOiIvecdUq/yV+ZfTGVFoIF1olZc2?= =?us-ascii?Q?ru3QTDwekgkXzQUialTJqTsou5SciTmhe0MS1cWrdQDkiO8Fs+DOEZaHuBJQ?= =?us-ascii?Q?WrpCWw1SpxsA/2qB8Sa3CUMeHyWnz5s13tLpuedu5HD39+18jZGX2zWPhp9j?= =?us-ascii?Q?EitETehzPMRXL4B7nzMgbtFz/JIzEo5TvgGVqRUd/DNNmdy3d05bMKzz63ei?= =?us-ascii?Q?6BmZ9ym3PrFI55Bg71XWjt5C7R4UVPIWaASHKRKau0E6ERB4IP4ZhtX6tAWF?= =?us-ascii?Q?wIjbOE0gaZd5aI3TxEG1Giyd5oSL/1mpI/6Ya65UtrC1xz/QTo8V6tmWE7hz?= =?us-ascii?Q?VB+41yrAEOAm5kNUFcmHupTfgZwETgFinwMXzEBMAnvASOR6wliZsNa1hJJ2?= =?us-ascii?Q?vDfD4qSvzKaKysdoR7Kj2a5lSpn4ZJemrEsQt+dGeG011Ea906EMH//Buurg?= =?us-ascii?Q?sdIJ9QcP2aKgSU6dhRJbPriBxwpow5Y04Ky4Tqeh1W80oezeaY1kiVxRSf39?= =?us-ascii?Q?lhQKKQpTjSHeY8V6VSeKktIeChVuP612lY4RydNT436WytAtrepRjHFuHylp?= =?us-ascii?Q?flqOY/KJq5rU7N4xjMFYVYgGVETxhKNXa8GCQx/DhUJM0BpAs9wFk+05XaT2?= =?us-ascii?Q?hxIfxNRyBZR4e3pV1Ele6/Jt+CzUVk/GU2altuy0hj8VGwtrKg8Daj18Acmd?= =?us-ascii?Q?Ge9hvkM2fkH1BygNT4sPbth1K/aoM6qd3LWwFQZBLF7vrgZgQmrLa3tCAJX1?= =?us-ascii?Q?H8VIQln6Mj+00i9Xq3odkHHftdQsDV1zn47wlL1arVwzP7+Jk0s22AI5ALx0?= =?us-ascii?Q?Mg0+fL9lW5GQfvL9y+l5PFVOM9q5GNGrAPbGVkkmoH9Tl31j+kt/RPyi26ij?= =?us-ascii?Q?kPNDs486jBoMzPXAkStU6g/76rwo6w7Uh7hxsRj5WchbvhC9NO3nWXbjvUrL?= =?us-ascii?Q?lq3YYh/hX37ZvVKW6dLRp3Oy?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB802; 5:eX99epI5DBsTAxwAvd/3KP4UduG17mv9NL1UiKdjeefvrwVOG0bGu2eyoKAcl9eVhe814MY5+IIKwUcSLNW1nbbqHA6v5wEKUDwtDqsrcUD8UjTMdIs/4386Ij4ns3kpD6Cw3JN9SRxsz7If+lY3Lg==; 24:J1clJDDTNgslykhuVcX0Fvv98MILhkfY8GZrI34ueX2JEEtFaGfnZAWK811asbs6CVK5XBs9Xwc2aJXAMX0ETVg6bH3q6QaZsPMa8KHNrvY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 23:28:20.8539 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB802 Archived-At: Cc: "openpgp@ietf.org" , Derek Atkins , Bryan Ford Subject: Re: [openpgp] [FORGED] RE: Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:28:44 -0000 Peter Gutmann writes: > Derek Atkins writes: > > I'm not sure what OpenPGP cards have to do with this, since I'm > talking about PKCS #11. I can use a PKCS #11 device with X.509, with > S/MIME, with TLS, with SSH, with IKE, and quite probably with a number > of other, lesser-known Internet security protocols. The one > significant one I can't use it with is PGP. I have not had any problems using PKCS#11 with GnuPG. See http://gnupg-pkcs11.sourceforge.net/ Most recently, I have used it with YubiKey NEO and YubiKey4. See https://www.yubico.com/products/yubikey-hardware/yubikey4/ -- Mark From nobody Mon Apr 11 17:13:33 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1A012D9F3 for ; Mon, 11 Apr 2016 17:13: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpI0jTs2lyUZ for ; Mon, 11 Apr 2016 17:13:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B548512D6D3 for ; Mon, 11 Apr 2016 17:13:30 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 492B5F997; Mon, 11 Apr 2016 20:13:29 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 181AF20143; Mon, 11 Apr 2016 20:13:24 -0400 (EDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , IETF OpenPGP In-Reply-To: References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> <20160410211449.GA12408@littlepip.fritz.box> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 11 Apr 2016 20:13:20 -0400 Message-ID: <87wpo3smzj.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] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 00:13:33 -0000 --=-=-= Content-Type: text/plain On Mon 2016-04-11 08:04:20 -0400, Phillip Hallam-Baker wrote: > Fingerprints are used for two purposes. > > 1) To define a trust anchor. > 2) To verify that a purported trust anchor is correct > > Only the first of these requires the ability to enter the fingerprint > at a keyboard. . For my own practice, i've found that i do better verification by typing in a fingerprint than by reading and checking in my own head. if i'm asked to compare two fingerprints that are displayed to me on different media (say, a computer screen and a business card), i observe that i simply lose patience and focus before the comparison is completed and tend to opt toward "yeah that's good enough". But with the other approach, it's pretty easy to power through the "data entry" task of transcribing the (relatively short) fingerprint from the business card to the computer, and just let the machine do the fingerprint comparison. I have no idea how prevalent these particular cognitive biases are with other humans, but i'd be reluctant to say that we should expect people to always do verification of fingerprints without data entry. > The most efficient way that is compliant with existing > keyboards etc. is Base32. While not all keyboards have latin > characters, there is an effective limit on the number of keys, screen > real estate etc. Here is a link to base32 encoding for folks who aren't used to it: https://tools.ietf.org/html/rfc4648#section-6 a base32-encoded bitstream should be marginally smaller than (it should be 80% as long as) the same bitstream encoded as hex. A 40-bit field would consume 8 octets in base32, but 10 octets in hex. i would really like us to make a clear recommendation for a common textual interchange format for these identifiers; i'm not convinced that it's actually out-of-scope for 4880bis. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXDD2gXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcK1JsQAMBQg6YOv/6rDlf3CbL6ustD C5qVYDEmGvbyWb+A/cS0idxs/thzETN4dtg9HvhWoLOU17nS226N0zhjqhXbie1R 5uCJ5Rxq7G4dtXtK9fDYG+C0ZNvvvAci0DZCd7UZ3eVqKt5jAihGLDHdWldHk1zp J3n6O5uDiqB8J4FdtVRhKOe/os0KDOIi/9MNvRg/yhFZt7u0/7tDOGJs0gPcTE4S oLppiIbsqCiZMaOfHQdCNVBBqBeiwbkRQykjRt1UGRiwh6XTYSjua0Ai9UFs+68S MS8qEmS7dvrCiaVErGiNUYK/6PtJG2ir6bDTdX2j179SJrSMPMajSP10uA7O8RZz rNljfNGp7a7olbl2fqZoe2XMZouxbFtZ643OZG6z/KEjNLf3IQ/kU+ngjyEqIxH1 EE/jXUGRhX5iIPXnfeNdjBI9Ds1c+SaPPQBAmipJW/LqfuSAI/QfOrdpL+Uv3qwL ngwF4oYErFzCckeudp6F+YAADwnVNkiNrUvcv6NIdzMrrIzATH8mO/GpulGBfhWK m4mBikkoySlfnRKNhh6tTw49r0NjKuRgathp2+9bCY4C49NucbwO/bkbMbuJ1WtQ l6IPSwUx+6kryhg6p1CJN6N2YI76MWRVhpoJ8ILomDH42GY7YMaIjs6pvEMHkKrL sbK4G2BBhRdcLJwQMdkr =Bi9F -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 11 17:40:27 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820112D7AA for ; Mon, 11 Apr 2016 17:40: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 489OASAApVs5 for ; Mon, 11 Apr 2016 17:40:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0AC12D757 for ; Mon, 11 Apr 2016 17:40:24 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 87539F991 for ; Mon, 11 Apr 2016 20:40:22 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 37E7C20143; Mon, 11 Apr 2016 20:40:22 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 11 Apr 2016 20:40:22 -0400 Message-ID: <87vb3nslqh.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 00:40:26 -0000 Hi all-- I was hoping to see someone write up the specific use cases for the OpenPGP fingerprint, but i haven't seen it yet, so i'm trying to do that here. I tend to agree with the discussion elsewhere in this thread that "internal database ID" is *not* the defining use case for the fingerprint, so i'm not including it here. I think there are only two use cases: a) looking up a particular OpenPGP key in some remote database like a public keyserver b) confirming that a particular key matches some out-of-band communication These are things that might happen by fingerprint transfer via any of: * business cards (pre-planned, printed) * scraps of paper (impromptu, hand-written) * over the telephone or other voice channels * copy and paste from a non-OpenPGP-specific message (chat, e-mail, etc) Note that a human is always in the loop in these transfers. If no human is in the loop, we do not need the fingerprint, and can (and probably should) use some other technique. As such, i think we have these human-specific constraints: * the fingerprint should be identifiable as a fingerprint, including where it starts and where it stops. * it should avoid ambiguity -- readers shouldn't have to puzzle over whether a character is an "o" or an "O" or a "0", for example, and writers shouldn't have to worry about it either. * there should be one (and exactly one) fingerprint per key; otherwise comparisons become impossible. * it should be as close as possible to the human attention span -- this is Vincent's point, i think. Humans really can't reliably deal with 512 bits of entropy when doing any kind of data entry or comparison. * data entry should be easy to do with standard tools And we have these machine-specific constraints: * it should be cheap to compute from a given key -- you shouldn't need a gig of RAM or a minute of CPU to calculate the fingerprints of any key. * it should be strong enough that we do not believe anyone can create a key with a fingerprint that collides with another key's fingerprint And these spec constraints: * it should be easy for implementers to understand and generate Is this problem framed correctly? If not, what's missing? If so, can someone try to apply it to one of the fingerprint proposals and see what the takeaway is? --dkg From nobody Tue Apr 12 01:34:18 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72A012E836 for ; Tue, 12 Apr 2016 01:34: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjASIfJ2XTuO for ; Tue, 12 Apr 2016 01:34:14 -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 7690D12E830 for ; Tue, 12 Apr 2016 01:34:13 -0700 (PDT) Received: from localhost (dhcp176-022.wlan.rz.tu-bs.de [134.169.176.22]) by mail.mugenguild.com (Postfix) with ESMTPSA id 29C655FAE3; Tue, 12 Apr 2016 10:34:12 +0200 (CEST) Date: Tue, 12 Apr 2016 10:34:09 +0200 From: Vincent Breitmoser To: Daniel Kahn Gillmor Message-ID: <20160412083409.GA16775@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <87vb3nslqh.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 08:34:16 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Daniel Kahn Gillmor(dkg@fifthhorseman.net)@Mon, Apr 11, 2016 at 08:40:22PM -0400: > * it should be as close as possible to the human attention span -- this > is Vincent's point, i think. Humans really can't reliably deal with > 512 bits of entropy when doing any kind of data entry or comparison. Yes. > * it should be cheap to compute from a given key -- you shouldn't need > a gig of RAM or a minute of CPU to calculate the fingerprints of any > key. Strictly speaking, we can be slightly less restrictive: It must be cheap to verify, given a fingerprint, that it's the correct one for a key. This distinction does not make a difference unless we store the fingerprints as part of the data format (which we probably shouldn't), so this is more of an academic point. > * it should be strong enough that we do not believe anyone can create a > key with a fingerprint that collides with another key's fingerprint Quite importantly, this should be "another *independent* key's fingerprint", i.e. the requirement is preimage resistance, not collision resistance. Creating two keys with colliding fingerprints is fine, at least noone could come up with a attack scenario where it mattered. - V --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDLMBAAoJEHvRgyDerfoRErIQALOaQ/yNZe6tAQtRVQwDu++8 2WUuNhayEnmlL1hTxk5t3ZfOkQS1G98pzZX74Y4EbYUI6TD2MOZR+nYVfVzNsJQu UcyLBIelvOfae/k35S80uRBPww3rwc+LLAF8Ai6OTs2q5AP+4D4IWF3fietycA4I s8+pLjrmlRooskMqeYtr1wksUtirjikLKIsF50zdf+D2WZX6Blt6AdpxdvNUJwGz kYqVpdWHKcuZs4nhrBQnZgY0/LoYFHjmjzZPdDRgz8TrkEDDH0fXkgls2r7pJYOS yG4NvclV2ze8+W/5R4GK5vd2A8v19A/KT9MoUXoDSwGEDZlmhiZN/WFpzTdLlK1P MKwKxOVZy+lQaSvO95jnVtWJ2x0qTb9EsLPbmO2+dyHzUx2LYc5ukEzKdlTMDC1n NtgYxhjiV/oTedueiLbC2hs2G7MTxcqegoF95+HyZzr/xNlhg70PaM4nLzuqUPj8 nNRSTw2qG/1zqUlfewunCud9dnfMv4/dFrrPC75G8DkXUjhG1aOeJ1StPDvteAfG t30AkXH4DhnRPZ0RWGg06DM27PSgQZ2OINH8fTwrnC7LgakYbrzHDJB8F9Pnz7Hq I1/k3shJQCKVRRI/Z8QQm3B0CNJl7ugoF6pvoTUFLIRyg5QsxtNxZdpBVo3tXs3t oW/cyld2W7fuMDWAtNLP =pBq2 -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From nobody Tue Apr 12 05:15:57 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EA112DF40 for ; Tue, 12 Apr 2016 05:15: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3rOdYWsqD51 for ; Tue, 12 Apr 2016 05:15:54 -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 7D0C612D10E for ; Tue, 12 Apr 2016 05:15:53 -0700 (PDT) Received: from localhost (dhcp176-217.wlan.rz.tu-bs.de [134.169.176.217]) by mail.mugenguild.com (Postfix) with ESMTPSA id 03D085FA25; Tue, 12 Apr 2016 14:15:51 +0200 (CEST) Date: Tue, 12 Apr 2016 14:15:49 +0200 From: Vincent Breitmoser To: IETF OpenPGP , openpgp-email Message-ID: <20160412121549.GB16775@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [openpgp] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 12:15:56 -0000 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, (crossposting to openpgp-email and openpgp-wg, the lists where I expect the highest rates of interested people) I'd like to discuss a thought that has come up in my work on k9 mail: Using OpenPGP in E-Mail without relying on keyservers. As a motivation, just consider someone spins up their botnet to add 1000 or more keys per second to the pool - aaaaand it's gone. Other aspects are that a keyserver lookup requires network connectivity, introduces noticable delay, and has privacy implications which prevent us from doing the lookup in an automated fashion. First, some basic considerations: To obtain the public key of a communication partner, we obviously have to rely on said communication partner to make their key available to us one way or another. The only deployed lookup mechanism are keyservers, but we said we don't have that. The alternative is sending the key in-band with the particular communication protocol: No problem for synchronous communication such as XMPP because we can simply request them, more difficult for e-mail where that option is not available. If we don't have bandwidth constraints, we can solve this by sticking the public key block right next to every signature we make, which effectively eliminates the need for keyservers (with the possible exception of the distribution of revocation certs). However, it also adds ~10kb of size to every signature. This is a rather extreme approach, and although 10kb are not a lot these days, they add up. To counteract this, we can significantly reduce the number of attached public keys if we are just a little bit clever about the decision of when to add it. Roughly, it makes sense to attach the public key to the first message of a conversation with each recipient. Another question is, where to place the key. In email, we have two options: in a separate mime part, or directly next to the pgp signature data. I favor the second option, for two reasons: - the email client has to know a lot less about openpgp for this to work, the public key is naturally handed to the openpgp-implementation together with the signature data. - there isn't yet another weird attachment for recipients who don't have openpgp support - the intended purpose of the key is clear, because there are no other circumstances where a key might end up in this position. The drawback with this approach is implementation support. If an implementation doesn't expect a public key next to the signature data, it's just bloat (or even worse, produces a warning about trailing data. I did some tests and this is the case in mutt, but not enigmail), and does not even show an option for the user to manually import the key. I think that this approach might be a way to overcome the need for a click from the user (whether it's "Retrieve from Keyserver" or "Import =66rom Attachment") to be able to import and work with a public key. It's unacceptable to import a key from keyservers automatically for various reasons, but I think an opt-out behavior of importing keys retrieved as part of a message is fine, if that key also signed the message. I'll leave it at this for now. I'd be delighted about comments and thoughts, in particular from those of you who are involved in the decision making of other implementations. - V --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDOb1AAoJEHvRgyDerfoRW04QAK2u+q7ulDyJyERE90YbhiyD GNO+gzBblVetThrJBowfbuvj86anddFBJ900JdoIbSyB25h11RXLr048d7muYeWA GVAex/kk43ixZahonmfpbeIv5Hvt42tjPkFeTTuhC7tE0AnGliB93WapucfM9BsF IhNn57hU3C7GDQCd6cC53mUgQuDo8EJVgQ+IZm5JScc5yQSPRjImP/SuL92dT0SX t6swJWDTmgBgJVCF+UyZ+cOtp+J95pJeDaXLYAKIbj4C2LrOU9lm5tqqIhgQuGPZ ilxLn4oTSV10Y5xfYh/PE4z+0O+8vTK/F6aoLanp7V4jFPMDhSYBQpxVwXmXiu+p wuUddVEPwxibWfzSMBOLHYY6L09z8NSAm3I1tuDM0Oy08wVAHt3fm242Xd6R/Dn+ UCj4uA0GbsSIL1KJsLHoP6+APLPrs3cClbHglxg42rzkikwxS/8PxHiKTAMzkl+a b6Xb2WrBr+RH3ls6nJpEIdJsT+dEieqPigftq7lJNxnqzbXhAgNrztsV7zcLZZ0V 3nPRTTfkvS3qqzRJDPQ+0J9WjkMkaKelIbQknKTp7I2HRntjUPS9RBJc9d7mDFrq E5UcmK0IQTgTT40eQofQAs4cu22ZhakRFtaVUYU631j7nj08tMjkKg+O8Hp33CpJ EI6wx9cQZVSS5jqc0Cn7 =1IJx -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From nobody Tue Apr 12 06:06:39 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8EA12ED34 for ; Tue, 12 Apr 2016 06:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofe6KR5Kypxk for ; Tue, 12 Apr 2016 06:06:32 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 40D0212D828 for ; Tue, 12 Apr 2016 06:06:32 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id t129so23128100vkg.2 for ; Tue, 12 Apr 2016 06:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9BU8lUeiPB8E+79Qe7n6N8S6+BP/NazA4uXILtwW594=; b=Hw5t7/tT3ralFgI/k9jP3Ia6A1Cg+dmCPRnQnWIUfuis4ySmW408U3edzbZAJpp8Yc 8vuseXN+IrunUZiAaitS6Qa5W1W79ak9k+I8wFftwi5XFqN+ELlo1ABe5W5cj/6xm3ds za4FeA8qliL8I76nrR1uTx49k+mYo94F3ITjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9BU8lUeiPB8E+79Qe7n6N8S6+BP/NazA4uXILtwW594=; b=RMlKK333qV15aXtG7E+b/DGnp0ZSrGFrtg5AhA+8BHQv0UG0QFQ8sobGM9mvVIMnOe t+WTcn9ma5Ibz27zE90Ihdqp/9wU2bANW0SBcK3J+k08uPH7PNmbWoP2e6iACGRaZLL5 j3KmziERDcZVewzbioijPgMgkqP2mz6Al+diK3ddbNkczmwHPsfM90MCGY2pT2JVT4G7 v8e5MGY9quwBlFvf9LtmUsU/Jo6DSJkUdbzlOKssY3+j9nKEeC+F1s+kMY4mc25Jo+GV qv5ydewXlw171jVOc3p2ac+ffGgQRwyEpwRlStfBbb5n+gIaVFHCLATfsF62HT6qWKcK BKEQ== X-Gm-Message-State: AOPr4FX/fL1+ftSPoyLAW/2NY+JUMMi+1degy9dBENnKGGrEDkJ2PD6FPHs3+zVAtQWQAigBHMixMFHM9IljmEoa X-Received: by 10.31.107.71 with SMTP id g68mr1593356vkc.15.1460466391335; Tue, 12 Apr 2016 06:06:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.94.3 with HTTP; Tue, 12 Apr 2016 06:06:11 -0700 (PDT) In-Reply-To: <20160412083409.GA16775@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> From: Joseph Lorenzo Hall Date: Tue, 12 Apr 2016 09:06:11 -0400 Message-ID: To: Vincent Breitmoser Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:06:37 -0000 On Tue, Apr 12, 2016 at 4:34 AM, Vincent Breitmoser wrote: > Quite importantly, this should be "another *independent* key's > fingerprint", i.e. the requirement is preimage resistance, not collision > resistance. Creating two keys with colliding fingerprints is fine, at > least noone could come up with a attack scenario where it mattered. I don't think I'm understanding this. If you have two keys that map to the same fingerprint, then an attacker can decide to serve you whichever is in their best interest. Doesn't that mean that fingerprint collisions from different keys is specifically something we want to avoid? Or am I missing the "*independent*" element of your comment here? -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Tue Apr 12 06:15:52 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BC912ED8A for ; Tue, 12 Apr 2016 06:15: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGR0GzAZ64WL for ; Tue, 12 Apr 2016 06:15: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 9493012EDC3 for ; Tue, 12 Apr 2016 06:15:49 -0700 (PDT) Received: from localhost (dhcp176-217.wlan.rz.tu-bs.de [134.169.176.217]) by mail.mugenguild.com (Postfix) with ESMTPSA id B2D9C5FC83; Tue, 12 Apr 2016 15:15:47 +0200 (CEST) Date: Tue, 12 Apr 2016 15:15:45 +0200 From: Vincent Breitmoser To: Joseph Lorenzo Hall Message-ID: <20160412131545.GA20078@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:15:51 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joseph Lorenzo Hall(joe@cdt.org)@Tue, Apr 12, 2016 at 09:06:11AM -0400: > If you have two keys that map to the same fingerprint, then an > attacker can decide to serve you whichever is in their best interest. The premise of your scenario is that you are already using a key generated by the attacker. What could an attacker possibly gain by possessing a second key with the same fingerprint? - V --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDPUBAAoJEHvRgyDerfoRoQkP/jzTyRnkrNOVmM2GeK0QYfzF ksHy+koEUwovLfKSy8BIvwzrrAUxWhgEJ/6rFfjNoCbeyP14nsqWXWsCRHKrVbSj QtgBdb8ZK3K4S7LStsc5Oov5TVvkG9jaYxV5N1lfFYxlfPGkN6UXv2HTyAUp1O91 K2sdekM0Alaz/LsvY1UL/cr0o0qgChDMexXjWkbJCM7SHAG9HrJevZcpG09/UUBC PMy8vFm0O7GTLhTktqy8fXP0B3hVceM/fkBsEvXhXw1cACLZEr2gSWqc6Fl57CB9 E0RYzqBdmrx+E5N9IlzPcc3JyjX5GP05NS52nj2M5kU0PVul7J7xtiAs52oz/pXC YrS4U8w09m28HWzQi7Q37rpDNpznZ+pyIWGkjexGRYlslmXEHtw5fe9vzlRSpqQ3 QHBtVfpkip4FYg7VECFLaOUymND6bnhLelQR1uhp8LBik8tfni6Z5eGruQx6RQaf QTBmjb/06u3rtIIZX/S+JYk5SjsC6b3d8aR7Vj07gHMtIgrgPMtWp6UNIKliR/rp 3IHcVKmHkK6riTaj0aDYUvKArKemQuRuffwBCd8hEkUWWL0IfIpJKTA1gPX2/QKS x8y27eGEcUvjlk752GDnW0nioX4+1HMs0iEvs3nik9gaYyTBXVh+EPdLxp155Bra sNYvNbgvcwtN4C0R+JnK =wX/t -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From nobody Tue Apr 12 06:16:00 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7964212EDDF for ; Tue, 12 Apr 2016 06:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCZ6mzUcfyWU for ; Tue, 12 Apr 2016 06:15:52 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B77E712ED8A for ; Tue, 12 Apr 2016 06:15:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qknVt183Hz390; Tue, 12 Apr 2016 15:15:50 +0200 (CEST) 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 3NyYjY1YGmEI; Tue, 12 Apr 2016 15:15:48 +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, 12 Apr 2016 15:15:48 +0200 (CEST) Received: from [10.210.2.31] (unknown [186.141.130.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id A99CB614B000; Tue, 12 Apr 2016 09:15:46 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A99CB614B000 References: <20160412121549.GB16775@littlepip.fritz.box> In-Reply-To: <20160412121549.GB16775@littlepip.fritz.box> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <29B66C8D-BAD3-42C6-A8E7-8D243FF45A02@nohats.ca> X-Mailer: iPhone Mail (13E238) From: Paul Wouters Date: Tue, 12 Apr 2016 10:15:36 -0300 To: Vincent Breitmoser Archived-At: Cc: IETF OpenPGP , openpgp-email Subject: Re: [openpgp] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:15:53 -0000 Have you looked at the openpgpkey DNS record which is going to be an RFC ver= y soon? https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 Paul Sent from my iPhone > On Apr 12, 2016, at 09:15, Vincent Breitmoser wrote= : >=20 > Hi, >=20 > (crossposting to openpgp-email and openpgp-wg, the lists where I expect > the highest rates of interested people) >=20 > I'd like to discuss a thought that has come up in my work on k9 mail: > Using OpenPGP in E-Mail without relying on keyservers. As a motivation, > just consider someone spins up their botnet to add 1000 or more keys per > second to the pool - aaaaand it's gone. Other aspects are that a > keyserver lookup requires network connectivity, introduces noticable > delay, and has privacy implications which prevent us from doing the > lookup in an automated fashion. >=20 > First, some basic considerations: To obtain the public key of a > communication partner, we obviously have to rely on said communication > partner to make their key available to us one way or another. The only > deployed lookup mechanism are keyservers, but we said we don't have > that. The alternative is sending the key in-band with the particular > communication protocol: No problem for synchronous communication such as > XMPP because we can simply request them, more difficult for e-mail where > that option is not available. >=20 > If we don't have bandwidth constraints, we can solve this by sticking > the public key block right next to every signature we make, which > effectively eliminates the need for keyservers (with the possible > exception of the distribution of revocation certs). However, it also > adds ~10kb of size to every signature. This is a rather extreme > approach, and although 10kb are not a lot these days, they add up. >=20 > To counteract this, we can significantly reduce the number of attached > public keys if we are just a little bit clever about the decision of > when to add it. Roughly, it makes sense to attach the public key to the > first message of a conversation with each recipient. >=20 > Another question is, where to place the key. In email, we have two > options: in a separate mime part, or directly next to the pgp signature > data. I favor the second option, for two reasons: > - the email client has to know a lot less about openpgp for this to > work, the public key is naturally handed to the openpgp-implementation > together with the signature data. > - there isn't yet another weird attachment for recipients who don't have > openpgp support > - the intended purpose of the key is clear, because there are no other > circumstances where a key might end up in this position. >=20 > The drawback with this approach is implementation support. If an > implementation doesn't expect a public key next to the signature data, > it's just bloat (or even worse, produces a warning about trailing data. > I did some tests and this is the case in mutt, but not enigmail), and > does not even show an option for the user to manually import the key. >=20 > I think that this approach might be a way to overcome the need for a > click from the user (whether it's "Retrieve from Keyserver" or "Import > from Attachment") to be able to import and work with a public key. It's > unacceptable to import a key from keyservers automatically for various > reasons, but I think an opt-out behavior of importing keys retrieved as > part of a message is fine, if that key also signed the message. >=20 > I'll leave it at this for now. I'd be delighted about comments and > thoughts, in particular from those of you who are involved in the > decision making of other implementations. >=20 > - V >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Apr 12 06:40:33 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FA712DFAB for ; Tue, 12 Apr 2016 06:40: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbsDuaN5Oc4q for ; Tue, 12 Apr 2016 06:40:26 -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 3690112DDFD for ; Tue, 12 Apr 2016 06:40:26 -0700 (PDT) Received: from localhost (dhcp176-217.wlan.rz.tu-bs.de [134.169.176.217]) by mail.mugenguild.com (Postfix) with ESMTPSA id 871725FAE3; Tue, 12 Apr 2016 15:40:24 +0200 (CEST) Date: Tue, 12 Apr 2016 15:40:22 +0200 From: Vincent Breitmoser To: Paul Wouters Message-ID: <20160412134022.GB20078@littlepip.fritz.box> References: <20160412121549.GB16775@littlepip.fritz.box> <29B66C8D-BAD3-42C6-A8E7-8D243FF45A02@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <29B66C8D-BAD3-42C6-A8E7-8D243FF45A02@nohats.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:40:32 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have, and it indeed solves the ddos-problem of keyservers. It still requires connectivity, introduces an arbitrary lookup delay, leaks metadata, and most importantly - it's not deployed. I would love to see it in action at scale, but even on my most hopeful of days I reckon it will be years until it's commonly supported by mail providers. - V Paul Wouters(paul@nohats.ca)@Tue, Apr 12, 2016 at 10:15:36AM -0300: > Have you looked at the openpgpkey DNS record which is going to be an RFC = very soon? >=20 > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 >=20 > Paul >=20 > Sent from my iPhone >=20 > > On Apr 12, 2016, at 09:15, Vincent Breitmoser wr= ote: > >=20 > > Hi, > >=20 > > (crossposting to openpgp-email and openpgp-wg, the lists where I expect > > the highest rates of interested people) > >=20 > > I'd like to discuss a thought that has come up in my work on k9 mail: > > Using OpenPGP in E-Mail without relying on keyservers. As a motivation, > > just consider someone spins up their botnet to add 1000 or more keys per > > second to the pool - aaaaand it's gone. Other aspects are that a > > keyserver lookup requires network connectivity, introduces noticable > > delay, and has privacy implications which prevent us from doing the > > lookup in an automated fashion. > >=20 > > First, some basic considerations: To obtain the public key of a > > communication partner, we obviously have to rely on said communication > > partner to make their key available to us one way or another. The only > > deployed lookup mechanism are keyservers, but we said we don't have > > that. The alternative is sending the key in-band with the particular > > communication protocol: No problem for synchronous communication such as > > XMPP because we can simply request them, more difficult for e-mail where > > that option is not available. > >=20 > > If we don't have bandwidth constraints, we can solve this by sticking > > the public key block right next to every signature we make, which > > effectively eliminates the need for keyservers (with the possible > > exception of the distribution of revocation certs). However, it also > > adds ~10kb of size to every signature. This is a rather extreme > > approach, and although 10kb are not a lot these days, they add up. > >=20 > > To counteract this, we can significantly reduce the number of attached > > public keys if we are just a little bit clever about the decision of > > when to add it. Roughly, it makes sense to attach the public key to the > > first message of a conversation with each recipient. > >=20 > > Another question is, where to place the key. In email, we have two > > options: in a separate mime part, or directly next to the pgp signature > > data. I favor the second option, for two reasons: > > - the email client has to know a lot less about openpgp for this to > > work, the public key is naturally handed to the openpgp-implementation > > together with the signature data. > > - there isn't yet another weird attachment for recipients who don't have > > openpgp support > > - the intended purpose of the key is clear, because there are no other > > circumstances where a key might end up in this position. > >=20 > > The drawback with this approach is implementation support. If an > > implementation doesn't expect a public key next to the signature data, > > it's just bloat (or even worse, produces a warning about trailing data. > > I did some tests and this is the case in mutt, but not enigmail), and > > does not even show an option for the user to manually import the key. > >=20 > > I think that this approach might be a way to overcome the need for a > > click from the user (whether it's "Retrieve from Keyserver" or "Import > > from Attachment") to be able to import and work with a public key. It's > > unacceptable to import a key from keyservers automatically for various > > reasons, but I think an opt-out behavior of importing keys retrieved as > > part of a message is fine, if that key also signed the message. > >=20 > > I'll leave it at this for now. I'd be delighted about comments and > > thoughts, in particular from those of you who are involved in the > > decision making of other implementations. > >=20 > > - V > >=20 > > _______________________________________________ > > openpgp mailing list > > openpgp@ietf.org > > https://www.ietf.org/mailman/listinfo/openpgp >=20 --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDPrGAAoJEHvRgyDerfoRrGAP/0Mz+EUeMMRog6sPTx1NS8i6 ufQuE7BQ9pS4F+oklVRYx6U0XV4ONdAEiRfx+ovifGePLrtTiKwBBhEoRkvjiwS4 thg+gH5zCPt+4CWjYQkDcSJ1OPtd6dB7wlgN5oiq40EI41zDEoUITigCglIZOCxe iCOmWavNzmfHptslOFUeT0/Tt5PsdSu7sFflhYTpKQuQFs07eqEYaBpx4cNi62/C mFGmlJOlLcF/v61f58VyL//P9P7v29SC0kqPRHftRj0Z258RWaNtC17JQvq+ZtMD qSBio8RgaSKi2X3WJPvwggV+oLblb7NDT0fhBEYScN1rGjxvZ4pY0j2ESn1W8gUa 7mFXkY1iKWqW2VaZcbhKtErQVVqaruyqQRTyb9X0ToRIcXe6Z1ZhNi/03fULBEMb hR7VLP/toPbNPenb/CFg21ULk0hXuqOqLO4ONOmePMbDyHvLQF0a6I6fpyeBWgRp Qt+HBRUdAnBYHLW/z4TDBeZZ4tjX1kzhKMce1MYjQxNeJ6pU6OvgsdKwUbjHYO65 RQZ9h9wnXjsdb8CmwUa4FdJLhgY8G5CSYbbuUHL9YNHEy1DsgGjlrkDpkKTe6svH hhn7Vsm2QdnCv1TgWbR4qWsFA/a58qL8wnRD6gkMe2A1muZxNgVlIJYW7Ev8P2Fe QBAGWeH3+atfIhsrzhaI =yCbd -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From nobody Tue Apr 12 06:49:42 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587A12E11B for ; Tue, 12 Apr 2016 06:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtR1kZxarQqo for ; Tue, 12 Apr 2016 06:49:37 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 031BE12E17E for ; Tue, 12 Apr 2016 06:49:36 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u3CDnN1x006638 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Apr 2016 15:49:24 +0200 Date: Tue, 12 Apr 2016 15:49:18 +0200 From: Simon Josefsson To: Vincent Breitmoser Message-ID: <20160412154918.1ca8da7c@latte.josefsson.org> In-Reply-To: <20160412121549.GB16775@littlepip.fritz.box> References: <20160412121549.GB16775@littlepip.fritz.box> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/DiSbgQw1soXV_CXJbQvK3DR"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: IETF OpenPGP , openpgp-email Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:49:41 -0000 --Sig_/DiSbgQw1soXV_CXJbQvK3DR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > I'd like to discuss a thought that has come up in my work on k9 mail: > Using OpenPGP in E-Mail without relying on keyservers.=20 Important use-case. > If we don't have bandwidth constraints, we can solve this by sticking > the public key block right next to every signature we make, which > effectively eliminates the need for keyservers (with the possible > exception of the distribution of revocation certs). However, it also > adds ~10kb of size to every signature. This is a rather extreme > approach, and although 10kb are not a lot these days, they add up. Not necessarily -- I don't think you have to add all signatures to the key for this use-case to work, do you? If you just include a stripped public key, verification of the signature will work. It should be max 1-2kb I would guess. > To counteract this, we can significantly reduce the number of attached > public keys if we are just a little bit clever about the decision of > when to add it. Roughly, it makes sense to attach the public key to > the first message of a conversation with each recipient. It sounds good in theory, but I don't think that will work. Let's compare how I use e-mail clients. I use k9, claws, evolution, webmail, and probably several other clients that I forgot. I don't read all emails in all clients, of course. I only read the emails that I need in the client I happen to have available. So if you only include the public key in the first message of a conversation, the majority of my clients would never see that email because of my usage pattern. None of any newly installed MUA would ever see the email, which over time tends to approach 100% of my MUAs since I re-install most of them from time to time. Now it may be that my usage pattern is a corner case, but I believe it is typical for many users today. > Another question is, where to place the key. In email, we have two > options: in a separate mime part, or directly next to the pgp > signature data. You could put it in the email header too. It would be bizare for larger keys, but at least possible in theory. Also, the OpenPGP mail/news url field header was intended to provide an indirect way to support this: http://josefsson.org/openpgp-header/ You still have some of the keyserver privacy concerns, and require a network connection, but I'd just like to mention it as another option to consider. > I favor the second option, for two reasons: I agree it could work. Write an I-D describing the approach and try to get MUA client support for it. /Simon --Sig_/DiSbgQw1soXV_CXJbQvK3DR Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXDPzfAAoJEIYLf7sy+BGdFK8IAKLnyiZUnNHnlhTrnPvBUAq4 5cxGfH3O9A5WcCPIyfneV/MYRh2vYkqRZ3KcKJvCwJPTt3OZr7aukCVhiQ6GPsOC 7L4DIglaFukKr2bmnfi9+j+I8pAZCBnmIhbkzvSRSh01EhtLXhqbMReNj4NZh+b9 uxCwogXU0KuLcVHZVICJjmbyj7hsMfEDNnLwMrzVCRUodaoMpHvPHVzfLqyNLKnX 6h6p8abVDnH/u0zPm/OoAmW5k/aSk0eX7VZDwypiBzgX3KANosibYnmvDWu8GdTA zr8bDFjCu79utxXEabPqsO5Y9m7tnG7yj+P1/EDudmPIyL5PkJbDUOpLHl8lKRs= =v7Zx -----END PGP SIGNATURE----- --Sig_/DiSbgQw1soXV_CXJbQvK3DR-- From nobody Tue Apr 12 06:58:34 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8A12E17E for ; Tue, 12 Apr 2016 06:58:32 -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, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_3OfpwYrmm8 for ; Tue, 12 Apr 2016 06:58:31 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 540A912D661 for ; Tue, 12 Apr 2016 06:58:31 -0700 (PDT) Received: from p5ddf9109.dip0.t-ipconnect.de ([93.223.145.9] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1apypm-0000DY-QV; Tue, 12 Apr 2016 13:58:27 +0000 Date: Tue, 12 Apr 2016 15:58:27 +0200 Message-ID: <87ziszq67w.wl-neal@walfield.org> From: "Neal H. Walfield" To: OpenPGP-based Email Encryption In-Reply-To: <20160412154918.1ca8da7c@latte.josefsson.org> References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:58:33 -0000 On Tue, 12 Apr 2016 15:49:18 +0200, Simon Josefsson wrote: > > I'd like to discuss a thought that has come up in my work on k9 mail: > > Using OpenPGP in E-Mail without relying on keyservers. > > Important use-case. > > > If we don't have bandwidth constraints, we can solve this by sticking > > the public key block right next to every signature we make, which > > effectively eliminates the need for keyservers (with the possible > > exception of the distribution of revocation certs). However, it also > > adds ~10kb of size to every signature. This is a rather extreme > > approach, and although 10kb are not a lot these days, they add up. > > Not necessarily -- I don't think you have to add all signatures to the > key for this use-case to work, do you? If you just include a stripped > public key, verification of the signature will work. It should be max > 1-2kb I would guess. I think 10kb is accurate. If you have a primary and three subkeys and all four have a self-signature, then you are about 10k: $ gpg2 -k 0xAACB3243630052D9 pub rsa3744/0xAACB3243630052D9 2015-04-07 [SC] [expires: 2025-04-04] Key fingerprint = 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 uid [ultimate] Neal H. Walfield uid [ultimate] Neal H. Walfield uid [ultimate] Neal H. Walfield sub rsa2048/0x7223B56678E02528 2015-04-07 [S] [expires: 2017-04-06] sub rsa2048/0xC2B819056C652598 2015-04-07 [E] [expires: 2017-04-06] sub rsa2048/0xA3506AFB820ABD08 2015-04-07 [A] [expires: 2017-04-06] $ gpg2 --export-options=export-minimal --export 0xAACB3243630052D9 | wc -c 9622 Of course, we can leave off the authorization key in this case. But, we need the primary key to verify the self-signatures, we need to the signing key to verify signatures and we need the encryption key to encrypt. So, this is pretty minimal. :) Neal From nobody Tue Apr 12 07:30:18 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EF412DE6A for ; Tue, 12 Apr 2016 07:30: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbLs6obA6m43 for ; Tue, 12 Apr 2016 07:30:15 -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 43BD812EE59 for ; Tue, 12 Apr 2016 07:30:14 -0700 (PDT) Received: from localhost (unknown [217.13.173.17]) by mail.mugenguild.com (Postfix) with ESMTPSA id 32B695FAE3; Tue, 12 Apr 2016 16:30:13 +0200 (CEST) Date: Tue, 12 Apr 2016 16:30:09 +0200 From: Vincent Breitmoser To: Simon Josefsson Message-ID: <20160412143009.GA31049@littlepip.fritz.box> References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <20160412154918.1ca8da7c@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP , openpgp-email Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:30:17 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Now it may be that my usage pattern is a corner case, but I believe it > is typical for many users today. Good point. I'll think about this some more. Two related ideas from the top of my head: - keyring synchronization. this is necessary to send an encrypted message to a known contact from a new device, so it's going to be a thing we will have to worry about somewhere down the line for proper support of the multi-device scenario. - store message-id of the message where the pubkey was last sent on the sender side, and add it to the mime header of the signature? for reasonably recent messages, clients should be able to make that lookup without network in many cases, and it avoids the privacy leak. > You could put it in the email header too. It would be bizare for > larger keys, but at least possible in theory. Yeah, 10kb header lines don't seem very practical. I also considered the mime header, but same argument, it's just too unwieldy. :\ > You still have some of the keyserver privacy concerns, and require > a network connection, but I'd just like to mention it as another option > to consider. Indeed: Connectivity, delay, privacy. :) > I agree it could work. Write an I-D describing the approach and try to > get MUA client support for it. Depending on the resonance I get or further arguments brought up here, I'm going to implement this in at least K-9 Mail myself. :) Thanks for the feedback so far! - V --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDQZxAAoJEHvRgyDerfoROr0P/j/btZSh7xcMiiHba74/ujZ0 NZQjVTxWCvCTojPR8Dvgd7AeOLQp4X/5bWZnsFEKKOyhe+2Il/g4jj1OMWEC3kJT pSTkdYNVdoFY/tytVLM/ZSEEmjK2RKPSeagKo7qLQQjJrSQDzTVd8xNtA0sfseBd 8WKU1ADStS/NYuYVaomo4yX5yCFvLL/manT/jD+2VyCdAE+mAoWe57E5cmIcckbJ wEjF5qfQ4ILlpkOi5YqQ9XzdeCVVSuZphV2ap8pKbXKBYjdiWS1X5kCD8ai1IaUH IuT+piypV4sPKnB3vtvjMFTDXBeh4SLosVF6C2tStM8xyHbD4DpzogEi7/M3knU6 qbxjVBm8UHVW52hQOVna7aujcT2PEw+AniKdla8o5QUaiEz9rk5dcX+oh66/oaz6 xi4YkG6ChOM2LQVSX4//1BtYHwJ5Xe57D4FVvWlUL/pQ56pGH1qxWlcmEo44v9Au MlNOX06y4hiPHlw4PpmHD38ym9IFRFGMXgPBpgxvtlaKTFBCBdU5zRuFo1eUzd1V WCjhZRJMfp7hfJWAAdqspqzzynmvzl0zj9yJc2+/lRZ9F/WrWgYRixhRI6KKg+Pt EoQUjlfsZXw3UKJiGq9V7qwvkTQvgOxN63Dr7a7RGvZlaOmfO767M6zQU24O+pHu j6jEPAnhaFiYMgg+sbMP =2pt6 -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From nobody Tue Apr 12 07:32:54 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25E212DD6E for ; Tue, 12 Apr 2016 07:32: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsAlbBFDVClz for ; Tue, 12 Apr 2016 07:32:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9E67E12D10F for ; Tue, 12 Apr 2016 07:32:49 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A77FDF997; Tue, 12 Apr 2016 10:32:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 21E7320072; Tue, 12 Apr 2016 10:32:48 -0400 (EDT) From: Daniel Kahn Gillmor To: Vincent Breitmoser In-Reply-To: <20160412083409.GA16775@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 10:32:47 -0400 Message-ID: <87egaarj74.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:32:52 -0000 On Tue 2016-04-12 04:34:09 -0400, Vincent Breitmoser wrote: >Daniel Kahn Gillmor(dkg@fifthhorseman.net)@Mon, Apr 11, 2016 at 08:40:22PM -0400: >> * it should be cheap to compute from a given key -- you shouldn't need >> a gig of RAM or a minute of CPU to calculate the fingerprints of any >> key. > > Strictly speaking, we can be slightly less restrictive: It must be > cheap to verify, given a fingerprint, that it's the correct one for a > key. This distinction does not make a difference unless we store the > fingerprints as part of the data format (which we probably shouldn't), > so this is more of an academic point. Right, i don't think we should store the fingerprint as part of the data format, so we still need to be able to rapidly generate it, not just verify it. >> * it should be strong enough that we do not believe anyone can create a >> key with a fingerprint that collides with another key's fingerprint > > Quite importantly, this should be "another *independent* key's > fingerprint", i.e. the requirement is preimage resistance, not > collision resistance. Creating two keys with colliding fingerprints > is fine, at least noone could come up with a attack scenario where it > mattered. This clarification also matches my understanding. Thanks for the precision, Vincent. --dkg From nobody Tue Apr 12 07:34:44 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FF512EE44 for ; Tue, 12 Apr 2016 07:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYH2FuT1-ogW for ; Tue, 12 Apr 2016 07:34:40 -0700 (PDT) Received: from eternauta.sindominio.net (eternauta.sindominio.net [80.81.122.47]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E687412EEBF for ; Tue, 12 Apr 2016 07:34:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by lesnaus.sindominio.net (Postfix) with ESMTP id 206744046E4; Tue, 12 Apr 2016 16:34:38 +0200 (CEST) Received: from eternauta.sindominio.net ([127.0.0.1]) by localhost (lesnaus.sindominio.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foc7QukMoWBn; Tue, 12 Apr 2016 16:34:32 +0200 (CEST) Received: from localhost (unknown [95.63.56.146]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by lesnaus.sindominio.net (Postfix) with ESMTPSA id 806804046E0; Tue, 12 Apr 2016 16:34:31 +0200 (CEST) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="===============6113357987027387068==" MIME-Version: 1.0 Content-Disposition: inline To: Simon Josefsson , "Vincent Breitmoser" From: Ruben Pollan In-Reply-To: <20160412154918.1ca8da7c@latte.josefsson.org> References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> Message-ID: <146047167027.5102.16171502176440717800@KingMob> Date: Tue, 12 Apr 2016 16:34:30 +0200 Archived-At: Cc: IETF OpenPGP , openpgp-email Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:34:43 -0000 --===============6113357987027387068== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Quoting Simon Josefsson (2016-04-12 15:49:18) > > To counteract this, we can significantly reduce the number of attached > > public keys if we are just a little bit clever about the decision of > > when to add it. Roughly, it makes sense to attach the public key to > > the first message of a conversation with each recipient. > = > It sounds good in theory, but I don't think that will work. Let's > compare how I use e-mail clients. I use k9, claws, evolution, webmail, > and probably several other clients that I forgot. I don't read all > emails in all clients, of course. I only read the emails that I need > in the client I happen to have available. So if you only include the > public key in the first message of a conversation, the majority of my > clients would never see that email because of my usage pattern. None > of any newly installed MUA would ever see the email, which over time > tends to approach 100% of my MUAs since I re-install most of them from > time to time. > = > Now it may be that my usage pattern is a corner case, but I believe it > is typical for many users today. In the multi-device world you are describing I think is pretty important to = share your keyring among your devices, not just your private keys, but all = your = known public keys and your trust on them. > > Another question is, where to place the key. In email, we have two > > options: in a separate mime part, or directly next to the pgp > > signature data. > = > You could put it in the email header too. It would be bizare for > larger keys, but at least possible in theory. > = > Also, the OpenPGP mail/news url field header was intended to provide an > indirect way to support this: > = > http://josefsson.org/openpgp-header/ > = > You still have some of the keyserver privacy concerns, and require > a network connection, but I'd just like to mention it as another option > to consider. In bitmask we do some of the things you propose Vincent. We attach public k= eys = to all sent emails until we get an email encrypted to this public key. We a= ttach = the key as a mime part, because enigmail already have support for that and = is = one click to import it in your keyring. We also add the OpenPGP header to all the sent emails and use it to discove= r = keys from the 'url' field if it's https and from the same domain than the e= mail = address. Even dough I have many concerns about key discovery on the key servers, I t= hink = we need key servers for key updates. We need to be able to revoke, extend = expiration, rotate subkeys, ... I think is really important for OpenPGP ema= il = clients to be able to update periodically the keyring in a 'privacy preserv= ing = way'. We even dream to have some crappy forward secrecy by rotating encrypt= ion = subkeys often, and deleting them from the keyring. -- = Ruben Pollan | http://meskio.net/ -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D- My contact info: http://meskio.net/crypto.txt -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D- Nos vamos a Croatan. --===============6113357987027387068== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Description: signature Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXDQd1AAoJECy5AH9CUIqHzJsP/iJpAmdcll4TQuaDSSd1ifNd CtgR0ZV+C7xK45lGDuUsaBqAQbCpqvhUr9QIDiO9NnzENcfYvf/RYuhyzaEA/RIC F29iM5v+3zSyKoblOOZ6Z584SMgFWVBPgBer6N3bp0WfHeoyYUUeE18zxnF0joTY V3H4mhK54o61IfnjRDNPgOPTeYczBq8bHYO7JziKBWw0zvfyBA2kZ7S557lDy2qH eCphOkZJDj7PgHmsDI3mbg4cIz74DOc0jqrBA6/awxLaa6j+o9UfoWa1fHp1fDO8 jopbE+Sse9RoF9A3cIll+w7GcTf3zlC9BHY6cuaL8ZtdJ9bSG2fmu82HCPsBCdB3 8rr+4nfdT1hmlpnjQC2NO/bMQWFmn6C/L77C9n/WE9Ul8iZx+X5uabvbKfe/lVk+ +Bz0wjc1DobFhDPRi+Yd2e+jkzCWdhY0vYDxSTFvO17CXvwasd/6WV4Y6n+Y6aw8 cyEBFA3M+oiP0Y0EbXhP2UzyOEQZ35uBf5PIS20p8PVgQcS2O9O0VYeofkBDPfkp oNgSOGXDtzSBDm6R+frIlF/D7bPAJjUtt0OUwEBSnAUU39Yg19pkpOCFvsYo0ayt GZdEK0TWsnorFdlImIB3qfnUclgMD2DqzN6q7V5dfsHW7swS6o4a01GbPTdE0WK0 KwPVHw67Wy63DZNfaSTF =1fHW -----END PGP SIGNATURE----- --===============6113357987027387068==-- From nobody Tue Apr 12 07:39:21 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3CD12E470 for ; Tue, 12 Apr 2016 07:39:19 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PQ_iVCHw6LZ for ; Tue, 12 Apr 2016 07:39:18 -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 AFAA312DB86 for ; Tue, 12 Apr 2016 07:39:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 47CDDE2039; Tue, 12 Apr 2016 10:38:45 -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 15940-07; Tue, 12 Apr 2016 10:38:40 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 34040E2030; Tue, 12 Apr 2016 10:38:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460471920; bh=jsQHrnDTxHKBTLbFSMuxGs9+cKap6t4Ekk5prrdmqUE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=LNUNR20w85WONNiKyuKzH1Y4btGsDQ5geZPk+6/tH7ALMW6Pc0KrqgJuq/aTg25aw rawiPcu+RZ0T7/hilPYT9yIq54uDveXMP/NR2p6wSE2ez7tpasG09TUnYoALWkJvN0 LrckNqNAI2qjsB3ddvX5hkm3jx3I/kuYrVKgUhGU= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3CEcU4r030130; Tue, 12 Apr 2016 10:38:30 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87vb3nslqh.fsf@alice.fifthhorseman.net> Date: Tue, 12 Apr 2016 10:38:29 -0400 In-Reply-To: <87vb3nslqh.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 11 Apr 2016 20:40:22 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:39:20 -0000 Hi, Thank you for your writeup.... Daniel Kahn Gillmor writes: [snip] > I tend to agree with the discussion elsewhere in this thread that > "internal database ID" is *not* the defining use case for the > fingerprint, so i'm not including it here. > > I think there are only two use cases: > > a) looking up a particular OpenPGP key in some remote database like a > public keyserver > > b) confirming that a particular key matches some out-of-band > communication I would argue that (b) is more important than (a). Your use-case (a) sounds more like a DB Handle, so arguably it should be elided because you've scoped your specification saying that "internal database ID is not the defining use case". Or are you saying that we have both an internal database ID and an external database ID? Beyond that, I agree with the rest of what you said. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 12 07:46:08 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9D12DF64 for ; Tue, 12 Apr 2016 07:46:06 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lYavzLR1a8H for ; Tue, 12 Apr 2016 07:46:05 -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 E0A4612D54A for ; Tue, 12 Apr 2016 07:46:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5D01DE2036; Tue, 12 Apr 2016 10:46:02 -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 15970-10; Tue, 12 Apr 2016 10:45:53 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 A67B1E2030; Tue, 12 Apr 2016 10:45:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460472352; bh=Mr3ld2J1GNFB5+OAMpSw6FTQRpEh0Ce6UtyCphVm9/w=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=QfKiGGXVpg+kwL67Io/Z8vzF+qy0mDFmv6JHf2YmfqYVwhzZhn6vBqMsB1Hw/Ixql 4+3noAhFVVwMUlDnDhA9ZwXM9MDlwuBgMF3i0kmwhxWX5iu74kQhSjLHi77lOiOGoa wN5QBBt01dftKYhqwnvvJwEp/7JynQfN29BVZf/8= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3CEjlm5030521; Tue, 12 Apr 2016 10:45:47 -0400 From: Derek Atkins To: Vincent Breitmoser References: <20160412121549.GB16775@littlepip.fritz.box> Date: Tue, 12 Apr 2016 10:45:47 -0400 In-Reply-To: <20160412121549.GB16775@littlepip.fritz.box> (Vincent Breitmoser's message of "Tue, 12 Apr 2016 14:15:49 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , openpgp-email Subject: Re: [openpgp] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:46:06 -0000 Hi, Vincent Breitmoser writes: > Hi, > > (crossposting to openpgp-email and openpgp-wg, the lists where I expect > the highest rates of interested people) > > I'd like to discuss a thought that has come up in my work on k9 mail: > Using OpenPGP in E-Mail without relying on keyservers. As a motivation, > just consider someone spins up their botnet to add 1000 or more keys per > second to the pool - aaaaand it's gone. Other aspects are that a > keyserver lookup requires network connectivity, introduces noticable > delay, and has privacy implications which prevent us from doing the > lookup in an automated fashion. > > First, some basic considerations: To obtain the public key of a > communication partner, we obviously have to rely on said communication > partner to make their key available to us one way or another. The only > deployed lookup mechanism are keyservers, but we said we don't have > that. The alternative is sending the key in-band with the particular > communication protocol: No problem for synchronous communication such as > XMPP because we can simply request them, more difficult for e-mail where > that option is not available. This is only an issue on the first communication with someone. Once you have your comminicant's key you can cache it locally and re-use it for all future transmissions without touching the keyserver. So really it's a question of bootstrapping: When you are sending an email to a person for the first time (or if you are verifying a signature for the first time), how do you get their key? This is, in my experience, a much more limited use-case. I find that I rarely send an email to someone for the first time, and rarely do I receive cold-call emails where I care about validating the signature. I'm usually sending (and receiving) emails to (from) the same people over and over. So once I acquire their key, it's cached and I don't need to ask for it again. Okay, so now that we're reduced the issue to first-use, how does one acquire that data? There are several options: 1) email unencrypted and ask for it 2) use a PGP keyserver 3) use some other lookup database (LDAP, DNS, etc) Pretty much every single one of these options implies some amount of delay and has different trust (and deployment) models. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 12 07:53:32 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB15E12DFB3 for ; Tue, 12 Apr 2016 07:53:30 -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, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDpENSUGjy2r for ; Tue, 12 Apr 2016 07:53:29 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 307BD12E03E for ; Tue, 12 Apr 2016 07:53:29 -0700 (PDT) Received: from p5ddf9109.dip0.t-ipconnect.de ([93.223.145.9] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1apzgw-0000bd-6i; Tue, 12 Apr 2016 14:53:22 +0000 Date: Tue, 12 Apr 2016 16:53:23 +0200 Message-ID: <87y48iri8s.wl-neal@walfield.org> From: "Neal H. Walfield" To: OpenPGP-based Email Encryption In-Reply-To: <146047167027.5102.16171502176440717800@KingMob> References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> <146047167027.5102.16171502176440717800@KingMob> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Simon Josefsson , IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:53:30 -0000 On Tue, 12 Apr 2016 16:34:30 +0200, Ruben Pollan wrote: > We even dream to have some crappy forward secrecy by rotating encryption > subkeys often, and deleting them from the keyring. Take a look at puncture encryption: https://isi.jhu.edu/~mgreen/forward_sec.pdf Matt wants to see this get integrated into OpenPGP at some point, but there are some issues. For instance, using puncture encryption, the private key can get larger than 64k, which is the current limit for OpenPGP private keys. :) Neal From nobody Tue Apr 12 09:13:24 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA3A12E1BD for ; Tue, 12 Apr 2016 09:13:23 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZQZ6xcQJ41G for ; Tue, 12 Apr 2016 09:13:22 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id E4FE712E0B2 for ; Tue, 12 Apr 2016 09:13:21 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 717ABF991; Tue, 12 Apr 2016 12:13:19 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 103B220143; Tue, 12 Apr 2016 12:13:19 -0400 (EDT) From: Daniel Kahn Gillmor To: Derek Atkins In-Reply-To: References: <87vb3nslqh.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 12:13:18 -0400 Message-ID: <87twj6pzz5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:13:23 -0000 On Tue 2016-04-12 10:38:29 -0400, Derek Atkins wrote: > Daniel Kahn Gillmor writes: > > [snip] >> I tend to agree with the discussion elsewhere in this thread that >> "internal database ID" is *not* the defining use case for the >> fingerprint, so i'm not including it here. >> >> I think there are only two use cases: >> >> a) looking up a particular OpenPGP key in some remote database like a >> public keyserver >> >> b) confirming that a particular key matches some out-of-band >> communication > > I would argue that (b) is more important than (a). Your use-case (a) > sounds more like a DB Handle, so arguably it should be elided because > you've scoped your specification saying that "internal database ID is > not the defining use case". Or are you saying that we have both an > internal database ID and an external database ID? yeah, i thought about this and went ahead with an inclusion of (a) anyway; think we don't need to specify any internal DB handles, but we do need a way to communicate across external database boundaries. I concede that if we define the fingerprint for use as an *external* DB handle, it's entirely likely (and reasonable) for implementers to use it as an internal DB handle as well, but i don't think we need to specify it as a target use case. If we say that use case (a) isn't a motivating use case for the fingerprint, do we have a story to tell about how an implementation might retrieve a specific key from an external database? or do we not need to tell that story? --dkg From nobody Tue Apr 12 09:23:41 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3378F12E2E1 for ; Tue, 12 Apr 2016 09:23:40 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09F5WUhDIN0b for ; Tue, 12 Apr 2016 09:23:39 -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 E0C5E12E2B5 for ; Tue, 12 Apr 2016 09:23:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A31C7E2030; Tue, 12 Apr 2016 12:23: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 16943-04; Tue, 12 Apr 2016 12:23:28 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 9B252E2036; Tue, 12 Apr 2016 12:23:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460478206; bh=s0+3R46LNSGydOcefQFwTGevUavOh6o0LzSPuRFJvrM=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=kiz2lCXihszsBSdZSbLOjxWNlXKg4C0ceaQsvwlWiEPCrJY7i4XGVddWMS8/wHGNF pFiwaR39OWkBDxbgO/E2NdYDKRNvAPq3BOG9PiAk6CcCRkJ1YdwaThIgkIhxgmZuhc davkADurSLhFDjWMx1cq/ywkk52OcLzQvSdAm/fU= Received: from 24.54.172.229 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 12 Apr 2016 12:23:26 -0400 Message-ID: In-Reply-To: <87twj6pzz5.fsf@alice.fifthhorseman.net> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87twj6pzz5.fsf@alice.fifthhorseman.net> Date: Tue, 12 Apr 2016 12:23:26 -0400 From: "Derek Atkins" To: "Daniel Kahn Gillmor" 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: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:23:40 -0000 Hi, On Tue, April 12, 2016 12:13 pm, Daniel Kahn Gillmor wrote: > On Tue 2016-04-12 10:38:29 -0400, Derek Atkins wrote: >> Daniel Kahn Gillmor writes: >> [snip] > yeah, i thought about this and went ahead with an inclusion of (a) > anyway; think we don't need to specify any internal DB handles, but we > do need a way to communicate across external database boundaries. Do we? > I concede that if we define the fingerprint for use as an *external* DB > handle, it's entirely likely (and reasonable) for implementers to use it > as an internal DB handle as well, but i don't think we need to specify > it as a target use case. That's kind of what's happened already, and it's what brought us to where we are. > If we say that use case (a) isn't a motivating use case for the > fingerprint, do we have a story to tell about how an implementation > might retrieve a specific key from an external database? or do we not > need to tell that story? When a human needs to look up a key there is usually some other identifier involved. Most likely it would be the UserID. The way I see the process is: 1) I receive business card or some other form that has email + Fingerprint 2) I download key from some server using the email address 3) I verify the key using the fingerprint (to make sure it's the right one). The fact that the fingerprint *could* be used as an identifier is what led us to these questions. If I want to verify a signature it can use the internal database ID -- no human interaction required. So I just don't see the use case where a human ONLY has a fingerprint without any other identifying information and needs to download the key. > --dkg -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 12 09:25:39 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857F512E3ED for ; Tue, 12 Apr 2016 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3kk8V26JnuS for ; Tue, 12 Apr 2016 09:25:36 -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 1E68012E40C for ; Tue, 12 Apr 2016 09:25:27 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq181-0003Pn-F6 for ; Tue, 12 Apr 2016 18:25:25 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq13V-0007NW-Im; Tue, 12 Apr 2016 18:20:45 +0200 From: Werner Koch To: Vincent Breitmoser References: <20160412121549.GB16775@littlepip.fritz.box> <29B66C8D-BAD3-42C6-A8E7-8D243FF45A02@nohats.ca> <20160412134022.GB20078@littlepip.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Vincent Breitmoser , Paul Wouters , IETF OpenPGP Date: Tue, 12 Apr 2016 18:20:45 +0200 In-Reply-To: <20160412134022.GB20078@littlepip.fritz.box> (Vincent Breitmoser's message of "Tue, 12 Apr 2016 15:40:22 +0200") Message-ID: <87d1puhk82.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Paul Wouters , IETF OpenPGP Subject: Re: [openpgp] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:25:38 -0000 On Tue, 12 Apr 2016 15:40, look@my.amazin.horse said: > I have, and it indeed solves the ddos-problem of keyservers. It still > requires connectivity, introduces an arbitrary lookup delay, leaks > metadata, and most importantly - it's not deployed. I would love to see Running DNS over Tor heavily mitigates the leak of meta data. If you run a decent gpg version on Windows and Tor is running, gpg will do just that w/o the need for further configuration. On Unix it is currently only possible with a patched ADNS version (because upstream is pretty slow to accept a patch to torify ADNS). There are privacy aware mail providers who offer OpenPGP DANE. For example try my callsign @ posteo.net [1]. We are currently talking to other mail providers to get them to deploy this or a similar https based key location mechanism. Salam-Shalom, Werner [1] For example by putting this into gpg.conf: auto-key-locate local,dane,pka,keyserver -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 09:30:30 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0AF12E4D4 for ; Tue, 12 Apr 2016 09:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68SvE0MLIl1Y for ; Tue, 12 Apr 2016 09:30:27 -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 0962C12E470 for ; Tue, 12 Apr 2016 09:30:27 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq1Cr-0003TI-Fy for ; Tue, 12 Apr 2016 18:30:25 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq1At-0007QS-L7; Tue, 12 Apr 2016 18:28:23 +0200 From: Werner Koch To: Bill Frantz References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Bill Frantz , openpgp@ietf.org, Bryan Ford Date: Tue, 12 Apr 2016 18:28:23 +0200 In-Reply-To: (Bill Frantz's message of "Thu, 7 Apr 2016 12:59:05 -0700") Message-ID: <874mb6hjvc.fsf@wheatstone.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, Bryan Ford Subject: Re: [openpgp] Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:30:29 -0000 On Thu, 7 Apr 2016 21:59, frantz@pwpconsult.com said: > fingerprints, so a fingerprint from one application can be input to > another application for verification (a very good idea Werner), or in That was not my idea, someone told me that they implemented it in their software. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 09:35:33 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38712DCF5 for ; Tue, 12 Apr 2016 09:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrJ5x_mT1Y6h for ; Tue, 12 Apr 2016 09:35: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 789E212E378 for ; Tue, 12 Apr 2016 09:35:27 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq1Hh-0003Xk-Tj for ; Tue, 12 Apr 2016 18:35:26 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq1EV-0007S9-Ix; Tue, 12 Apr 2016 18:32:07 +0200 From: Werner Koch To: "Mark D. Baushke" References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> <20151110021943.GH3896@vauxhall.crustytoothpaste.net> <72665D15-F685-41F6-A477-8E65DBBC5A04@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C42AC4@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C56BF1@uxcn10-5.UoA.auckland.ac.nz> <9652a57c1e22f4ac3d417aebca44851c.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73F4C57DA7@uxcn10-5.UoA.auckland.ac.nz> <87608.1460417298@eng-mail01.juniper.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "Mark D. Baushke" , Peter Gutmann , "openpgp\@ietf.org" , Derek Atkins , Bryan Ford Date: Tue, 12 Apr 2016 18:32:07 +0200 In-Reply-To: <87608.1460417298@eng-mail01.juniper.net> (Mark D. Baushke's message of "Mon, 11 Apr 2016 16:28:18 -0700") Message-ID: <87zisyg54o.fsf@wheatstone.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" , Derek Atkins , Bryan Ford , Peter Gutmann Subject: Re: [openpgp] [FORGED] RE: Fingerprint schemes versus what to fingerprint X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:35:32 -0000 On Tue, 12 Apr 2016 01:28, mdb@juniper.net said: > I have not had any problems using PKCS#11 with GnuPG. > See http://gnupg-pkcs11.sourceforge.net/ Which uses an internal interface of GnuPG and thus breaks with newer GnuPG versions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 09:47:17 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5512E760 for ; Tue, 12 Apr 2016 09:47: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLtRgfqpqazx for ; Tue, 12 Apr 2016 09:47:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBA912E75D for ; Tue, 12 Apr 2016 09:47:15 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C71C7F991; Tue, 12 Apr 2016 12:47:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 66EC7200B0; Tue, 12 Apr 2016 12:47:14 -0400 (EDT) From: Daniel Kahn Gillmor To: Derek Atkins In-Reply-To: References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87twj6pzz5.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 12:47:14 -0400 Message-ID: <877fg2bwq5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:47:16 -0000 On Tue 2016-04-12 12:23:26 -0400, Derek Atkins wrote: > When a human needs to look up a key there is usually some other identifier > involved. Most likely it would be the UserID. > > The way I see the process is: > 1) I receive business card or some other form that has email + Fingerprint > 2) I download key from some server using the email address > 3) I verify the key using the fingerprint (to make sure it's the right one). > > The fact that the fingerprint *could* be used as an identifier is what led > us to these questions. right, thanks for pushing on this. I'm curious what the rest of the WG thinks about this use case. if we can simplify the requirement down to just (b) that would be nice. One concern i have with existing keyserver infrastructure is that anyone can upload a key with any e-mail address. This could result in a lookup that returns dozens or hundreds of keys. Being able to constrain a lookup by a stable, unforgeable identifier mitigates this flooding attack. I'm not saying that mitigation is necessarily important enough to make it a guiding requirement for the fingerprint, though. And perhaps this lookup-flood is an issue that could be fixed some other way too? wdyt? --dkg From nobody Tue Apr 12 09:52:54 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569B412E946 for ; Tue, 12 Apr 2016 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB304AAbHcRH for ; Tue, 12 Apr 2016 09:52:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64312E84D for ; Tue, 12 Apr 2016 09:52:51 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AC623433424; Tue, 12 Apr 2016 16:52:50 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9621D43341E; Tue, 12 Apr 2016 16:52:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1460479970; bh=BF28BT2POT9pZDs6QjhkhSIppi52hUWLr6twEd61kt4=; l=336; h=From:To:CC:Date:References:In-Reply-To:From; b=qSjdq6BUZe+XwfIOCYp/rAow0okHQhK83Luh/NQljrIpG44k9ZL71RvGNQydgcSa3 /Vx9hRPycsK5tE9j8iEr2amRxs0EqgFDfE7fbjxjSF1El9rw9AB55GIBD4Hf+3Dffl FaclmIQi5hpenD6oKwYPDDUbFBt8gX6jB/JMP6Uc= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 937591FC88; Tue, 12 Apr 2016 16:52:50 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 12 Apr 2016 12:52:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Tue, 12 Apr 2016 12:52:49 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , Derek Atkins Thread-Topic: [openpgp] Fingerprint requirements for OpenPGP Thread-Index: AQHRlFPrwI/Mg5AAj0SZk4jochYzg5+GaY9NgABdSgCAAALVAIAABqYA//++THA= Date: Tue, 12 Apr 2016 16:52:49 +0000 Message-ID: <501e915a203a436193f15331cf99d1c7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87twj6pzz5.fsf@alice.fifthhorseman.net> <877fg2bwq5.fsf@alice.fifthhorseman.net> In-Reply-To: <877fg2bwq5.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.121] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:52:53 -0000 > One concern i have with existing keyserver infrastructure is that anyone = can > upload a key with any e-mail address. This could result in a lookup that > returns dozens or hundreds of keys. It would be nice if PGP were so successful :) The keyservers can address this by sending PGP-encrypted "please confirm" e= mail. From nobody Tue Apr 12 10:02:36 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B761D12E47F for ; Tue, 12 Apr 2016 10:02: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deEEnfkkIG2H for ; Tue, 12 Apr 2016 10:02:33 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B472F12E372 for ; Tue, 12 Apr 2016 10:02:26 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C2A98F991; Tue, 12 Apr 2016 13:02:25 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A9CF8200B0; Tue, 12 Apr 2016 13:02:25 -0400 (EDT) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Derek Atkins In-Reply-To: <501e915a203a436193f15331cf99d1c7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87twj6pzz5.fsf@alice.fifthhorseman.net> <877fg2bwq5.fsf@alice.fifthhorseman.net> <501e915a203a436193f15331cf99d1c7@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 13:02:25 -0400 Message-ID: <87y48iahge.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:02:34 -0000 On Tue 2016-04-12 12:52:49 -0400, "Salz, Rich" wrote: >> One concern i have with existing keyserver infrastructure is that anyone can >> upload a key with any e-mail address. This could result in a lookup that >> returns dozens or hundreds of keys. > > It would be nice if PGP were so successful :) I agree with you, but this concern isn't about success, it's about a malicious flooding attack :/ > The keyservers can address this by sending PGP-encrypted "please confirm" email. that doesn't work with the model of the keyserver network, where untrusted peer keyservers gossip data between each other. i'm pretty sure we don't want a "please confirm" e-mail from each keyserver operator, and i think most keyserver operators don't want the responsibility of running such a vetting service. If the answer is "throw away the keyserver network" then that's one thing; but if we think there needs to be a public directory lookup, then we need a clear explanation of how that works. i understand from Vincent's recent thread that people seem to be actively thinking about alternatives, which is a Good Thing. but even Vincent's thread doesn't seem to cover revocation. --dkg From nobody Tue Apr 12 10:05:35 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA4C12DC01 for ; Tue, 12 Apr 2016 10:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFZDFQGFGn64 for ; Tue, 12 Apr 2016 10:05:27 -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 CCECD12D7A4 for ; Tue, 12 Apr 2016 10:05:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq1kj-0003gv-9N for ; Tue, 12 Apr 2016 19:05:25 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq1gg-0007dl-J2; Tue, 12 Apr 2016 19:01:14 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87vb3nslqh.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 12 Apr 2016 19:01:14 +0200 In-Reply-To: <87vb3nslqh.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 11 Apr 2016 20:40:22 -0400") Message-ID: <87potug3s5.fsf@wheatstone.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] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:05:34 -0000 On Tue, 12 Apr 2016 02:40, dkg@fifthhorseman.net said: > Note that a human is always in the loop in these transfers. If no human > is in the loop, we do not need the fingerprint, and can (and probably > should) use some other technique. Given that the fingerprint is of constant size or at least has an upper limit, it has advantages in protocol design too. I can see only two other options: - Some newly made-up identifier. This brings us back to the X.509 mess of several ways to locate a key. - Using the the full public key: This would be fine for ECC, is troublesome for RSA, and for PQC it would be ridiculous large. Thus I think a binary fingerprint is even preferable with no humans in the loop. > * it should be cheap to compute from a given key -- you shouldn't need > a gig of RAM or a minute of CPU to calculate the fingerprints of any > key. According to Peter, this means SHA-256. There may be no proof-of-work to for creating a key and thus a structured fingerprint. (Sometimes you have to create a lot of one-off keys.) > * it should be strong enough that we do not believe anyone can create a > key with a fingerprint that collides with another key's fingerprint As Vincent pointed out, we only need preimage resistance. > If not, what's missing? Whether to hash a a) fixed string and a creation date, b) fixed string and creation date and a hard expiration date, c) fixed string, d) nothing in addition to the algorithm parameters. My conclusion from the discussions is that we should to decide between a) and c). I don't really care given that using a creation date of 0 can be used when needed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 10:15:32 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E018912B034 for ; Tue, 12 Apr 2016 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLzBZADVVtLj for ; Tue, 12 Apr 2016 10:15: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 D741B12D60E for ; Tue, 12 Apr 2016 10:15:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq1uP-0003jz-BF for ; Tue, 12 Apr 2016 19:15:25 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq1qY-0007hz-Nz; Tue, 12 Apr 2016 19:11:26 +0200 From: Werner Koch To: "Neal H. Walfield" References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> <146047167027.5102.16171502176440717800@KingMob> <87y48iri8s.wl-neal@walfield.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "Neal H. Walfield" , OpenPGP-based Email Encryption , Simon Josefsson , IETF OpenPGP , Vincent Breitmoser Date: Tue, 12 Apr 2016 19:11:26 +0200 In-Reply-To: <87y48iri8s.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 12 Apr 2016 16:53:23 +0200") Message-ID: <87h9f6g3b5.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Simon Josefsson , IETF OpenPGP , Vincent Breitmoser , OpenPGP-based Email Encryption Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:15:31 -0000 On Tue, 12 Apr 2016 16:53, neal@walfield.org said: > private key can get larger than 64k, which is the current limit for > OpenPGP private keys. Fur only for the computation of the fingerprint. We should address that for the v5 fingerprint. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 10:20:30 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4442012DDF9 for ; Tue, 12 Apr 2016 10:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGJGcSnluhQO for ; Tue, 12 Apr 2016 10:20:27 -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 B7F8E12D9A3 for ; Tue, 12 Apr 2016 10:20:27 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq1zG-0003oR-2S for ; Tue, 12 Apr 2016 19:20:26 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq1wy-0007kS-IB; Tue, 12 Apr 2016 19:18:04 +0200 From: Werner Koch To: Derek Atkins References: <87vb3nslqh.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 12 Apr 2016 19:18:04 +0200 In-Reply-To: (Derek Atkins's message of "Tue, 12 Apr 2016 10:38:29 -0400") Message-ID: <87d1pug303.fsf@wheatstone.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 , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:20:29 -0000 On Tue, 12 Apr 2016 16:38, derek@ihtfp.com said: > I would argue that (b) is more important than (a). Your use-case (a) > sounds more like a DB Handle, so arguably it should be elided because (a) is required to lookup a key for a signature. Sure this could also be done using mail address included in the signature. But a fingerprint can work even if a mail provider re-assigns a mail address (assuming the mail provider uses OpenPGP DANE or PKA). Right now a signature includes only a keyid but for rfc4880bis we will add a new subpacket for the fingerprint. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 10:23:10 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052B812E0BE for ; Tue, 12 Apr 2016 10:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVczRBoCBX3A for ; Tue, 12 Apr 2016 10:23:07 -0700 (PDT) Received: from mail.hashbang.sh (mail.hashbang.sh [104.236.230.244]) (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 F397E12DFE3 for ; Tue, 12 Apr 2016 10:23:06 -0700 (PDT) Received: from to1.hashbang.sh (to1.hashbang.sh [104.245.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hashbang.sh (Postfix) with ESMTPS id 26E4C3CF7; Tue, 12 Apr 2016 17:23:06 +0000 (UTC) Received: by to1.hashbang.sh (Postfix, from userid 3412) id 1A17CE00BA; Tue, 12 Apr 2016 17:22:46 +0000 (UTC) Date: Tue, 12 Apr 2016 17:22:46 +0000 From: KellerFuchs To: Daniel Kahn Gillmor Message-ID: <20160412172246.GE9034@hashbang.sh> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87egaarj74.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:23:09 -0000 On Tue, Apr 12, 2016 at 10:32:47AM -0400, Daniel Kahn Gillmor wrote: > On Tue 2016-04-12 04:34:09 -0400, Vincent Breitmoser wrote: > >Daniel Kahn Gillmor(dkg@fifthhorseman.net)@Mon, Apr 11, 2016 at 08:40:22PM -0400: > >> * it should be strong enough that we do not believe anyone can create a > >> key with a fingerprint that collides with another key's fingerprint > > > > Quite importantly, this should be "another *independent* key's > > fingerprint", i.e. the requirement is preimage resistance, not > > collision resistance. Creating two keys with colliding fingerprints > > is fine, at least noone could come up with a attack scenario where it > > mattered. > > This clarification also matches my understanding. Thanks for the > precision, Vincent. I think it is sane here to require collision resistence, because that's what multi-target preimages devolves to: an attacker might not want to target one specific key, but one amongst a large set of key (says, the developers of a popular software, or perhaps any “widely signed” key in the WoT). In that case, the attacker gets a non-trivial speedup, and as the set of targets grows larger, the hardness of the problem devolves into that of finding a collision. Moreover, colision resistence implies second-preimage resistence, and hash functions are usually considered “broken” by cryptographers once there is an attack for colisions, so it seems OK to be somewhat cautious here and require collisions to be hard. From nobody Tue Apr 12 10:45:02 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64712D65F for ; Tue, 12 Apr 2016 10:45:00 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AgK3vfhSwzM for ; Tue, 12 Apr 2016 10:44:59 -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 2375712D62C for ; Tue, 12 Apr 2016 10:44:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B6154E2030; Tue, 12 Apr 2016 13:44:25 -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 17350-07; Tue, 12 Apr 2016 13:44:19 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 04F71E2038; Tue, 12 Apr 2016 13:44:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460483058; bh=/Iv5gWzm+WQhCrR+yjc0+OwSsahr0GloWpy1cQpbCLQ=; h=In-Reply-To:References:Date:Subject:From:To; b=VBMyxlB14WNEd+NwAxerVmQ1Q8Ke1kA39eL7OIdpgPLmh/BpYba/I5liiKq4CYCM4 N87cQFYF7k/LXiInmxNXs+zqKGlQB884BmAfi8ZLy0fEpjNEPMQGAYGF39ON4KYG6b 0gVuarMlFMD/uFKnGzrJiwwmJqRZAcvyg180r4iI= Received: from 24.54.172.229 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 12 Apr 2016 13:44:17 -0400 Message-ID: <85d83d5bac518c53d7a78d5d049a73ed.squirrel@mail2.ihtfp.org> In-Reply-To: <87d1pug303.fsf@wheatstone.g10code.de> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87d1pug303.fsf@wheatstone.g10code.de> Date: Tue, 12 Apr 2016 13:44:17 -0400 From: "Derek Atkins" To: "Derek Atkins" , "Daniel Kahn Gillmor" , "IETF OpenPGP" 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: Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:45:01 -0000 Werner, On Tue, April 12, 2016 1:18 pm, Werner Koch wrote: > On Tue, 12 Apr 2016 16:38, derek@ihtfp.com said: > >> I would argue that (b) is more important than (a). Your use-case (a) >> sounds more like a DB Handle, so arguably it should be elided because > > (a) is required to lookup a key for a signature. Sure this could also > be done using mail address included in the signature. But a fingerprint > can work even if a mail provider re-assigns a mail address (assuming the > mail provider uses OpenPGP DANE or PKA). > > Right now a signature includes only a keyid but for rfc4880bis we will > add a new subpacket for the fingerprint. This would fall under an "internal DB Identifier." DKG called that out of scope for this discussion topic. There is no human in the loop here. That means it does not need to be "the same" as the user-visible "fingerprint". > Shalom-Salam, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 12 11:18:35 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA0112E8C1 for ; Tue, 12 Apr 2016 11:18:35 -0700 (PDT) X-Quarantine-ID: <3dqITY5h32dt> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dqITY5h32dt for ; Tue, 12 Apr 2016 11:18:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id AE80212E7D4 for ; Tue, 12 Apr 2016 11:18:32 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 30301F991; Tue, 12 Apr 2016 14:18:31 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id AEDE420072; Tue, 12 Apr 2016 14:18:25 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch In-Reply-To: <87potug3s5.fsf@wheatstone.g10code.de> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87potug3s5.fsf@wheatstone.g10code.de> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 14:18:25 -0400 Message-ID: <87potuadxq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: [openpgp] proof-of-work fingerprints [was: Re: Fingerprint requirements for OpenPGP] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 18:18:35 -0000 On Tue 2016-04-12 13:01:14 -0400, Werner Koch wrote: > According to Peter, this means SHA-256. There may be no proof-of-work > to for creating a key and thus a structured fingerprint. (Sometimes you > have to create a lot of one-off keys.) The one proposal i've heard that keeps things somewhat simple but still allows the possibility of an increased cost to an adversary intent on a preimage attack is related to floating point implementations, and was suggested by PHB. I try to describe my understanding of the scheme below, but writing it all down makes me think that "somewhat simple" might be overselling it; there are quite a few complications. Here goes: * Start from a design of a fingerprint of X bits, using a truncation of digest of size Z (where Z > X). for example, a 200-bit fingerprint from sha-256. this would typically mean an adversary has to do about 2^200 sha-256 operations to find a match. (this is an impossibly high bar if we're talking about brute force, but if we assume that most cryptanalysis of SHA-256 allows an attacker to shave off some sizeable work factor, it represents the "safety margin" against unknown cryptanalysis of this type) * Instead, make the fingerprint X+N bits, where the first N bits indicate the number of leading zeros of the digest. Now if i do a bit of work to generate keys with, say, 10 leading zeros, an attacker will probably need to do about 2^10 more digests to find a match. So if we're doing a 200-bit truncation of sha-256, and we have an 8-bit count of leading zeros, and the digest produced is (in hex -- i'm not making an argument about choice of textual representation here, just showing in hex for discussion): 001a1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2 then it would result in a fingerprint of (again in hex for discussion): 0ba1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da5 That is: 11 (0x0b) bits of zeros, followed by a 1 bit, followed by a1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da5 More precisely, under this scheme, fingerprint generation looks like: scan1(x) : the position of the left-most 1 bit in bitstring x A[n:m] : bits n through m-1 of bitstring A enc(n,b) : a bitstring of length b encoding n as an unsigned int dgst(x) : a fixed-length bitstring digest of bitstring x (e.g. sha-256) X : number of explicitly-represented bits N : size of bitfield for counting leading zeros || : bitstring concatenation def fpr(z): h = dgst(z) k = scan1(z) return enc(k,N) || h[z+1:z+1+X] * note that first bit that is set to 1 is omitted from the representation (it's present by implication). This isn't just a hack to squeeze one more bit of entropy out of the fingerprint, it's arguably necessary to ensure that there is exactly one fingerprint that corresponds to any given digest. Otherwise, i can represent a fingerprint with 3 leading zero bits as: <3> 1100101... or: <2> 01100101... or: <1> 001100101... or: <0> 0001100101... The other alternative is to require that the leading bit after the zero-run prefix is always 1 (unless the zero-run prefix is maxed out?), which would mean that certain fingerprints are simply invalid (we'd want tools to reject them?) * note also that for some choices of dgst and N it would mean there could be some keys that are un-fingerprintable. For example, if we chose dgst = sha-256 and N = 5, then any key that has a sha-256 digest with a leading run of more than 31 zeros might be unrepresentable. With all these caveats, i confess the much-simpler construction "200-bit truncation of sha-256" looks pretty appealing :) --dkg From nobody Tue Apr 12 11:38:10 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FD12DAF3 for ; Tue, 12 Apr 2016 11:38:08 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8h-pe8rFSPu for ; Tue, 12 Apr 2016 11:38:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5212DA7B for ; Tue, 12 Apr 2016 11:38:07 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CCE08F991; Tue, 12 Apr 2016 14:38:05 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 768D1200B0; Tue, 12 Apr 2016 14:38:05 -0400 (EDT) From: Daniel Kahn Gillmor To: KellerFuchs In-Reply-To: <20160412172246.GE9034@hashbang.sh> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net> <20160412172246.GE9034@hashbang.sh> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 14:38:05 -0400 Message-ID: <87mvoyad0y.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 18:38:08 -0000 On Tue 2016-04-12 13:22:46 -0400, KellerFuchs wrote: > I think it is sane here to require collision resistence, because that's what > multi-target preimages devolves to: an attacker might not want to target > one specific key, but one amongst a large set of key (says, the developers > of a popular software, or perhaps any “widely signed” key in the WoT). > > In that case, the attacker gets a non-trivial speedup, and as the set of > targets grows larger, the hardness of the problem devolves into that of > finding a collision. The size of the set of possible targets is relevant here, though, right? if the pool of available targets is 2^16, you're not going to get more than a 2^16 speedup by targeting them. Even if we had a separate key for every IPv4 address, that'd only be a 32-bit reduction in work factor. by comparison, a pre-image brute force costs 2^(2X) when a collision attack costs 2^X due to the "birthday paradox". We're talking about fingerprints in the range of 2^160 (the OpenPGPv4 fingerprint) and 2^256 (probably the upper bound of what we can expect humans to be able to deal with). so you'd need a pool of keys to attack on the order of 2^80 or 2^128 to get a comparable speedup. > Moreover, colision resistence implies second-preimage resistence, and hash > functions are usually considered “broken” by cryptographers once there is > an attack for colisions, so it seems OK to be somewhat cautious here and > require collisions to be hard. I think we're in quite a bit of trouble if we actually need both collision resistance and any sort of plausible human-accessibility for high-entropy strings. --dkg From nobody Tue Apr 12 12:55:30 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95512E373 for ; Tue, 12 Apr 2016 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5sKyEQVswe4 for ; Tue, 12 Apr 2016 12:55:27 -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 8757812E0C8 for ; Tue, 12 Apr 2016 12:55:27 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aq4PF-0004nu-LN for ; Tue, 12 Apr 2016 21:55:25 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aq4L8-0000Ba-Uu; Tue, 12 Apr 2016 21:51:10 +0200 From: Werner Koch To: "Derek Atkins" References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87d1pug303.fsf@wheatstone.g10code.de> <85d83d5bac518c53d7a78d5d049a73ed.squirrel@mail2.ihtfp.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "Derek Atkins" , "Daniel Kahn Gillmor" , "IETF OpenPGP" Date: Tue, 12 Apr 2016 21:51:10 +0200 In-Reply-To: <85d83d5bac518c53d7a78d5d049a73ed.squirrel@mail2.ihtfp.org> (Derek Atkins's message of "Tue, 12 Apr 2016 13:44:17 -0400") Message-ID: <87wpo2ehch.fsf@wheatstone.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 , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 19:55:29 -0000 On Tue, 12 Apr 2016 19:44, derek@ihtfp.com said: > This would fall under an "internal DB Identifier." DKG called that out of > scope for this discussion topic. It is not "internal" because it is part of the OpenPGP protocol (Signature Packet) and thus visible by all who are verifying a signature. I define "internal" as a property of the implementation - maybe this is the misunderstanding. > There is no human in the loop here. That means it does not need to be > "the same" as the user-visible "fingerprint". Need not, right. But adding yet another identifier to a key only leads to more confusion and more complex error handling. I do not expect that you want OpenPGP to repeat the error made by X.509. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 12 15:26:56 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3549812D7B1 for ; Tue, 12 Apr 2016 15:26:55 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9uGmWR5Q8uv for ; Tue, 12 Apr 2016 15:26:54 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 092B812D0CC for ; Tue, 12 Apr 2016 15:26:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id A04DF94BF939; Tue, 12 Apr 2016 15:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWR31MHNGrOX; Tue, 12 Apr 2016 15:26:44 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 97C4494BF922; Tue, 12 Apr 2016 15:26:42 -0700 (PDT) Received: from [10.119.8.236] ([209.73.142.2]) by keys.merrymeet.com (PGP Universal service); Tue, 12 Apr 2016 15:26:44 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 12 Apr 2016 15:26:44 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: <87vb3nslqh.fsf@alice.fifthhorseman.net> Date: Tue, 12 Apr 2016 15:26:42 -0700 Message-Id: References: <87vb3nslqh.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP , Jon Callas Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 22:26:55 -0000 > On Apr 11, 2016, at 5:40 PM, Daniel Kahn Gillmor = wrote: >=20 > Is this problem framed correctly? >=20 > If not, what's missing? Actually, I don't think it's framed correctly. I don't think distinguishing between local and remote databases is = necessary; I know I'm picking a nit here, but the design of many systems = is such that there isn't a difference. But moreover, a real remote = database is as likely to need to answer the question, "give me the = key(s) for " where the identifier might be a fingerprint and = might be something like an email address. Like I wrote before, there are two major uses for a "fingerprint," a = handle and an auth string.=20 Moreover the auth-string use case of fingerprints is actually the auth = string of the crypto key that is the top-level signing key of the "PGP = key", which is a data structure that usually consists of at least two = crypto keys. But the handle that turns into a key id is presently derived from the = fingerprint of a subkey that's used for encryption. I think it's completely reasonable to update the standard to take the = old-style fingerprint into better hash functions than SHA-1. It's = imperfect but it's the devil we know. If you want to move into devils we don't know, then why *not* make an = auth-string that is a different thing than handle? As you're describing the use cases, you've described something that you = can't solve. There's nothing wrong with noting that both circles and = squares have desirable properties, but you're not going to get = space-filling circles or a square that's got the perimeter equidistant = from the center.=20 Jon From nobody Tue Apr 12 18:01:09 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47C912DC7B for ; Tue, 12 Apr 2016 18:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv89x9gzVchz for ; Tue, 12 Apr 2016 18:01:06 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id B787212DC4C for ; Tue, 12 Apr 2016 18:01:06 -0700 (PDT) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aq9Au-0007xl-IE for openpgp@ietf.org; Tue, 12 Apr 2016 21:00:56 -0400 Date: Tue, 12 Apr 2016 18:00:51 -0700 From: Bill Frantz To: IETF OpenPGP 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.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7919da346378ac443265b20a7da6374429350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Archived-At: Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 01:01:08 -0000 I have not heard anyone arguing that we don't need some form of=20 fingerprint that can be typed into a computer for comparison.=20 (Several have argued that eyeball comparison is error prone.) Well, typing random data is error prone too. Perhaps we should=20 have some form of check digit(s) so the program processing the=20 type in can flag bad data entry and not confuse it with=20 fingerprint match failure. Cheers - Bill -------------------------------------------------------------- Bill Frantz | There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray From nobody Wed Apr 13 00:25:34 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C789D12D63D for ; Wed, 13 Apr 2016 00:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qhMSJ5Yvi7Q for ; Wed, 13 Apr 2016 00:25:30 -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 AA0AA12D1B8 for ; Wed, 13 Apr 2016 00:25:29 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aqFB1-0000iQ-3e for ; Wed, 13 Apr 2016 09:25:27 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aqF6T-00049a-Qn; Wed, 13 Apr 2016 09:20:45 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87potug3s5.fsf@wheatstone.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP Date: Wed, 13 Apr 2016 09:20:45 +0200 In-Reply-To: <87potug3s5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 12 Apr 2016 19:01:14 +0200") Message-ID: <877fg2dlf6.fsf@wheatstone.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] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 07:25:32 -0000 On Tue, 12 Apr 2016 19:01, wk@gnupg.org said: > discussions is that we should to decide between a) and c). I don't > really care given that using a creation date of 0 can be used when > needed. Of course we would add a creation date self-signature subpacket which is used iff the creation date from the public key packet is 0. This allows to see which scheme implementations will prefer. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 13 07:20:55 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC412DA11 for ; Wed, 13 Apr 2016 07:20:54 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzEoYW28gXPE for ; Wed, 13 Apr 2016 07:20:53 -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 26C6612D963 for ; Wed, 13 Apr 2016 07:20:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6B903E2038; Wed, 13 Apr 2016 10:20:50 -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 25547-02; Wed, 13 Apr 2016 10:20:46 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 4761EE2030; Wed, 13 Apr 2016 10:20:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460557246; bh=2Ljv1mlZM3owdKRFT5OWbKEhgMLzsqYoCYBgfKZYchA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=hGrT/U7EpfRm6tFmkApEE84gEWF1t5GMh9lV+ndj3vAzgeQT5RRBobJszMMWa+GxK vR1tsiHSfYr96MvXbiXkIJzEg1DWAiCs9uSegR6/zmN07FK5JHWmJGGhQg9/YfyrgX chy0LjWDAi0Lxpwua51VSQAWMkdGxZsOc5hYCn84= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3DEKarV026287; Wed, 13 Apr 2016 10:20:36 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net> Date: Wed, 13 Apr 2016 10:20:36 -0400 In-Reply-To: <87egaarj74.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 12 Apr 2016 10:32:47 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:20:54 -0000 Daniel Kahn Gillmor writes: > On Tue 2016-04-12 04:34:09 -0400, Vincent Breitmoser wrote: >>Daniel Kahn Gillmor(dkg@fifthhorseman.net)@Mon, Apr 11, 2016 at >> 08:40:22PM -0400: >>> * it should be cheap to compute from a given key -- you shouldn't need >>> a gig of RAM or a minute of CPU to calculate the fingerprints of any >>> key. >> >> Strictly speaking, we can be slightly less restrictive: It must be >> cheap to verify, given a fingerprint, that it's the correct one for a >> key. This distinction does not make a difference unless we store the >> fingerprints as part of the data format (which we probably shouldn't), >> so this is more of an academic point. > > Right, i don't think we should store the fingerprint as part of the data > format, so we still need to be able to rapidly generate it, not just > verify it. Nothing stops an implementation from storing the computed fingerprint alongside the key/certificate. Indeed, I would encourage implementations to do just that for speed, especially with extremely large keyrings. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 13 07:22:32 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD2B12DC55 for ; Wed, 13 Apr 2016 07:22:30 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k2y_zx9UqFj for ; Wed, 13 Apr 2016 07:22:28 -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 2A58712DBD3 for ; Wed, 13 Apr 2016 07:22:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5322BE2038; Wed, 13 Apr 2016 10:22:26 -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 25547-03; Wed, 13 Apr 2016 10:22:22 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 C3D6FE2030; Wed, 13 Apr 2016 10:22:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460557341; bh=Z/VngCWL9Ct3PnnX7R2BFJByuflHA96JYEfGTb8ylhI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=baXaU0WUNBJyVgiaaQc/FO73yzsowfj8PGYGJzzYQXrR28D7LdWU4BHPqRdIvM+Kk 36nW+Yk8XnuR6Ir1GnoO0+/zKex4+dWIfqez/IRvbwwPoimW/2rLOdn7sxppza+DOk Xu8WxZY2axTNEmj1HKVhnpD7dz19gnPwDUXdrO9c= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3DEMHMl026390; Wed, 13 Apr 2016 10:22:17 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net> <20160412172246.GE9034@hashbang.sh> <87mvoyad0y.fsf@alice.fifthhorseman.net> Date: Wed, 13 Apr 2016 10:22:17 -0400 In-Reply-To: <87mvoyad0y.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 12 Apr 2016 14:38:05 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (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 , KellerFuchs , Vincent Breitmoser Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:22:30 -0000 Daniel Kahn Gillmor writes: > On Tue 2016-04-12 13:22:46 -0400, KellerFuchs w= rote: >> I think it is sane here to require collision resistence, because that's = what >> multi-target preimages devolves to: an attacker might not want to targ= et >> one specific key, but one amongst a large set of key (says, the develo= pers >> of a popular software, or perhaps any =E2=80=9Cwidely signed=E2=80=9D = key in the WoT). >> >> In that case, the attacker gets a non-trivial speedup, and as the set of >> targets grows larger, the hardness of the problem devolves into that of >> finding a collision. > > The size of the set of possible targets is relevant here, though, right? > if the pool of available targets is 2^16, you're not going to get more > than a 2^16 speedup by targeting them. Even if we had a separate key > for every IPv4 address, that'd only be a 32-bit reduction in work > factor. > > by comparison, a pre-image brute force costs 2^(2X) when a collision > attack costs 2^X due to the "birthday paradox". > > We're talking about fingerprints in the range of 2^160 (the OpenPGPv4 > fingerprint) and 2^256 (probably the upper bound of what we can expect > humans to be able to deal with). > > so you'd need a pool of keys to attack on the order of 2^80 or 2^128 to > get a comparable speedup. This was my thought, too. The pool isn't going to get large enough to really bring the preimage work down to collision-level work. >> Moreover, colision resistence implies second-preimage resistence, and ha= sh >> functions are usually considered =E2=80=9Cbroken=E2=80=9D by cryptogra= phers once there is >> an attack for colisions, so it seems OK to be somewhat cautious here a= nd >> require collisions to be hard. > > I think we're in quite a bit of trouble if we actually need both > collision resistance and any sort of plausible human-accessibility for > high-entropy strings. > > --dkg > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 13 07:28:04 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077012DDC2 for ; Wed, 13 Apr 2016 07:28:02 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZZy4QMZlUTk for ; Wed, 13 Apr 2016 07:28:01 -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 012D112DDB5 for ; Wed, 13 Apr 2016 07:28:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 61DA9E2036; Wed, 13 Apr 2016 10:26:51 -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 25547-05; Wed, 13 Apr 2016 10:26:37 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 56A96E2039; Wed, 13 Apr 2016 10:26:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460557596; bh=+kl3WXgLX6ziCLebBHYaxASbSnfQhTo8WG/+4MZ/1u4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=YoR1T8M/ocSUBjZOXa2zqyVdaGood9zDnBSTrY3hDRpazL1pVI5s4Ircshidhv/3r xunowgUe7dbEcGPivIZygm5y7V0Dl+DEtRlwW6Ini0AKYZ088VIJhsrSfODjhYNImT zIyAXSXpPOgBJKym7bea7YHue91X9Qd4SiuUWX18= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3DER5B0026678; Wed, 13 Apr 2016 10:27:05 -0400 From: Derek Atkins To: "Derek Atkins" References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87d1pug303.fsf@wheatstone.g10code.de> <85d83d5bac518c53d7a78d5d049a73ed.squirrel@mail2.ihtfp.org> <87wpo2ehch.fsf@wheatstone.g10code.de> Date: Wed, 13 Apr 2016 10:27:04 -0400 In-Reply-To: <87wpo2ehch.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 12 Apr 2016 21:51:10 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:28:03 -0000 Werner, Werner Koch writes: > On Tue, 12 Apr 2016 19:44, derek@ihtfp.com said: > >> This would fall under an "internal DB Identifier." DKG called that out of >> scope for this discussion topic. > > It is not "internal" because it is part of the OpenPGP protocol > (Signature Packet) and thus visible by all who are verifying a > signature. > > I define "internal" as a property of the implementation - maybe this is > the misunderstanding. Probably. To me the key part of "internal" means "a human never sees it". I'm considering "internal" to be "in the data formats", which can be used between implementations and not just within a single implementation. >> There is no human in the loop here. That means it does not need to be >> "the same" as the user-visible "fingerprint". > > Need not, right. But adding yet another identifier to a key only leads > to more confusion and more complex error handling. I do not expect that > you want OpenPGP to repeat the error made by X.509. We already, to some degree, have that issue. There's the keyID and there's the fingerprint. They are different (although with v4 one is derived from the other). I think we need to step back again and keep in mind that the (human) authenticaton fingerprint may (should?) be different from the (internal or external) database identifer string. > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 13 07:31:31 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDE912D618 for ; Wed, 13 Apr 2016 07:31:30 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYMF2l2NWzS3 for ; Wed, 13 Apr 2016 07:31:27 -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 50CBC12D71E for ; Wed, 13 Apr 2016 07:31:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EF176E2038; Wed, 13 Apr 2016 10:28:23 -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 25547-07; Wed, 13 Apr 2016 10:28:08 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 DE1EFE2036; Wed, 13 Apr 2016 10:27:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460557672; bh=lT5MT2NAU6OTBn0KK5uSZqFVuzse/QAG3mS8c8HR1Gc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=I+Wliq102AVCi4A+LmMsnbrj1Zdu72Ry3wDaccP0foxbHClq2Q2siAlyOc59sxDrD V9WmfTOb8p9QUGjq5GBVFlwKdOI8b2wPfYiEd8cq5YLC8JDpLNOSlXIwdI1cK+W4lT MaalQ5Qn/xqzX+m4J2t2QMFkMbZey+UkmlemaqmU= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3DEUAsj026883; Wed, 13 Apr 2016 10:30:10 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87potug3s5.fsf@wheatstone.g10code.de> Date: Wed, 13 Apr 2016 10:30:05 -0400 In-Reply-To: <87potug3s5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 12 Apr 2016 19:01:14 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:31:30 -0000 Werner Koch writes: > On Tue, 12 Apr 2016 02:40, dkg@fifthhorseman.net said: > >> Note that a human is always in the loop in these transfers. If no human >> is in the loop, we do not need the fingerprint, and can (and probably >> should) use some other technique. > > Given that the fingerprint is of constant size or at least has an upper > limit, it has advantages in protocol design too. I can see only two > other options: > > - Some newly made-up identifier. This brings us back to > the X.509 mess of several ways to locate a key. > > - Using the the full public key: This would be fine for ECC, is > troublesome for RSA, and for PQC it would be ridiculous large. > > Thus I think a binary fingerprint is even preferable with no humans in > the loop. Agreed. >> * it should be cheap to compute from a given key -- you shouldn't need >> a gig of RAM or a minute of CPU to calculate the fingerprints of any >> key. > > According to Peter, this means SHA-256. There may be no proof-of-work > to for creating a key and thus a structured fingerprint. (Sometimes you > have to create a lot of one-off keys.) > >> * it should be strong enough that we do not believe anyone can create a >> key with a fingerprint that collides with another key's fingerprint > > As Vincent pointed out, we only need preimage resistance. > >> If not, what's missing? > > Whether to hash a > > a) fixed string and a creation date, > b) fixed string and creation date and a hard expiration date, > c) fixed string, > d) nothing > > in addition to the algorithm parameters. My conclusion from the > discussions is that we should to decide between a) and c). I don't > really care given that using a creation date of 0 can be used when > needed. I still believe we should use b, with the knowledge that the hard expiration is optional (could be 0). This would protect against an attack where you lose control of your secret material and the attacker creates a new self-sig with a new expiration time. > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 13 08:24:14 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A8212DADE for ; Wed, 13 Apr 2016 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP_sA9VUoxpZ for ; Wed, 13 Apr 2016 08:24:12 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 3D41C12D7D1 for ; Wed, 13 Apr 2016 08:24:08 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id k1so74344812vkb.0 for ; Wed, 13 Apr 2016 08:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9baUOmKKKgEvcv1OAFAAEPdfaZsAEoyDMalmXGWjNe4=; b=M7qG5pnEYn+MU6OT/X7aCDNvZkcSyRIAUlFpRqlDNt3YTOgqCPi16alOfkI4idYmuj 9OAezHbf8G/oSJwVs8gb4xPwu+X7XDEsK8oO2SwKK6D5kXzYk3RpoAATLC7MZLXZX23n hfteikvEBAjloxWa0BzH3x23iL+Iajdt4CWJo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9baUOmKKKgEvcv1OAFAAEPdfaZsAEoyDMalmXGWjNe4=; b=V/4mgfP1uvnuJdfzzAhpev/00HhCW3XxA94zwl/Jtzdzp/naYofI4Z/bxWzRjlCiAB bXVmB2KbCX4S/lnS+uAxrpSOD1Wk1GqExVDRnn+pGPy7TAOL+ikUXAyU62JVHCbFiq1l oQikHcWo9yt3AukJPqKvE0BtKcpfTXD/Cv7cIZ0+GTNRetXrI24mKgkqwSrhvW90DbpK 3mqQM1uw3BOhhR8d3uAQQR0O4NDABMnprvNVah7wNWCgoHpGdsSFHdxkkuQzPKZQvRNe JVG8BPqYKApJz66/x5wvaTanVECjN65OhBaU/+DmgNMCSA6VUtLu+MmHMDW8cvh302ei C9TA== X-Gm-Message-State: AOPr4FXYQ0XpQpTI0LmfKK2cLsHesQ1k0Tt8FJqgueQuvs8lFmTpjrTPngpnkNt1xICGeNu7UZw0iart8ktofQWz X-Received: by 10.176.1.202 with SMTP id 68mr5044871ual.12.1460561043704; Wed, 13 Apr 2016 08:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.94.3 with HTTP; Wed, 13 Apr 2016 08:23:44 -0700 (PDT) In-Reply-To: <20160412131545.GA20078@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <20160412131545.GA20078@littlepip.fritz.box> From: Joseph Lorenzo Hall Date: Wed, 13 Apr 2016 11:23:44 -0400 Message-ID: To: Vincent Breitmoser Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 15:24:13 -0000 On Tue, Apr 12, 2016 at 9:15 AM, Vincent Breitmoser wrote: > Joseph Lorenzo Hall(joe@cdt.org)@Tue, Apr 12, 2016 at 09:06:11AM -0400: >> If you have two keys that map to the same fingerprint, then an >> attacker can decide to serve you whichever is in their best interest. > > The premise of your scenario is that you are already using a key > generated by the attacker. What could an attacker possibly gain by > possessing a second key with the same fingerprint? Sorry so slow to respond... my premise is that increasingly I query for full fprs to obain keys from keyservers and if that maps onto two different keys with the same UserID that would be bad. I guess what the rest of the thread here is saying is that it would be so computationally difficult for a malicious keyserver to find a collision that this isn't a problem. (apologies for being somewhat dense) -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Wed Apr 13 09:00:32 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ED912D762 for ; Wed, 13 Apr 2016 09:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOIOAtPBWRRo for ; Wed, 13 Apr 2016 09:00: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 D1D0A12D1A4 for ; Wed, 13 Apr 2016 09:00:28 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aqNDP-0004gq-1i for ; Wed, 13 Apr 2016 18:00:27 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aqNC7-0007M2-GF; Wed, 13 Apr 2016 17:59:07 +0200 From: Werner Koch To: Derek Atkins References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87d1pug303.fsf@wheatstone.g10code.de> <85d83d5bac518c53d7a78d5d049a73ed.squirrel@mail2.ihtfp.org> <87wpo2ehch.fsf@wheatstone.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Derek Atkins , IETF OpenPGP , Daniel Kahn Gillmor Date: Wed, 13 Apr 2016 17:59:07 +0200 In-Reply-To: (Derek Atkins's message of "Wed, 13 Apr 2016 10:27:04 -0400") Message-ID: <87zisxa4ac.fsf@wheatstone.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 , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:00:31 -0000 On Wed, 13 Apr 2016 16:27, derek@ihtfp.com said: > We already, to some degree, have that issue. There's the keyID and > there's the fingerprint. They are different (although with v4 one is > derived from the other). In GnuPG 2.1 we removed support for v3 keys and thus we do not need to care about the difference between keyid and fingerprints anymore. This takes away a lot of burden we had with them (in particular storing the keyid for fast lookups). Using a truncated fingerprint for the keyid, as we have in v4, is easier. > I think we need to step back again and keep in mind that the (human) > authenticaton fingerprint may (should?) be different from the (internal > or external) database identifer string. Okay. But the new scheme should allow to derive the human authentication fingerprint from the internal fingerprint w/o the need for additional input. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 13 09:05:30 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B412D5B6 for ; Wed, 13 Apr 2016 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTBDNe2ExeKd for ; Wed, 13 Apr 2016 09:05: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 A46DF12B01D for ; Wed, 13 Apr 2016 09:05:28 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1aqNIF-0004iJ-4q for ; Wed, 13 Apr 2016 18:05:27 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1aqNF3-0007NP-5k; Wed, 13 Apr 2016 18:02:09 +0200 From: Werner Koch To: Derek Atkins References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87potug3s5.fsf@wheatstone.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Date: Wed, 13 Apr 2016 18:02:09 +0200 In-Reply-To: (Derek Atkins's message of "Wed, 13 Apr 2016 10:30:05 -0400") Message-ID: <87vb3la45a.fsf@wheatstone.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 , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:05:30 -0000 On Wed, 13 Apr 2016 16:30, derek@ihtfp.com said: > I still believe we should use b, with the knowledge that the hard > expiration is optional (could be 0). This would protect against an > attack where you lose control of your secret material and the attacker > creates a new self-sig with a new expiration time. Although I do not see a real need for this, I would accept this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 13 10:07:59 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C6812DE37 for ; Wed, 13 Apr 2016 10:07: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D7JmiIxkgmb for ; Wed, 13 Apr 2016 10:07: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 5657112DEDB for ; Wed, 13 Apr 2016 10:07:55 -0700 (PDT) Received: from localhost (dhcp183-119.wlan.rz.tu-bs.de [134.169.183.119]) by mail.mugenguild.com (Postfix) with ESMTPSA id E569A5FC83; Wed, 13 Apr 2016 19:07:53 +0200 (CEST) Date: Wed, 13 Apr 2016 19:07:51 +0200 From: Vincent Breitmoser To: KellerFuchs Message-ID: <20160413170751.GA4283@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net> <20160412172246.GE9034@hashbang.sh> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20160412172246.GE9034@hashbang.sh> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 17:07:58 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > usually considered =E2=80=9Cbroken=E2=80=9D by cryptographers This is not the general case cryptographers talk about, but a specific use case with a very specific set of requirements. > so it seems OK to be somewhat cautious here and require collisions > to be hard. If we could get it for free, maybe. But collision resistance is a factor two in bitsize, which is not only not free, but pretty darn costly. Just to get a feeling for the numbers, let's do some good old pessimistic math: We take a 128 bit fingerprint. We say the attacker wants to attack a pool of 65000 keys, so 2^16. That leaves 112 bits of fingerprint to attack. We also assume that an attacker can test as fast as they can generate sha-256 hashes, and give no penalties for key generation, multi-target attack, collisions or stuff like that. Top of the line hashing ASICs are at about 5 terahashes per second. But let's just say our attacker has 10 terahashes/s (2^43) per device for ease of math. Then let's say our attacker has one *billion* of those devices (2^30), which is a ridunculous number to have. In this scenario, our attacker needs 2^(128-16-43-30) =3D 2^39 seconds to find a single preimage, which is 17432 years. =46rom a different angle, for one Joule of energy (=3D 1 watt-second) you can very optimistically get about 5T (2^42) sha256 hashes for one Joule of energy. For 2^112 hashes, that's 2^(112-42) =3D 2^70 Joule of energy, or 2^19 terawatt-hours of energy. For comparison, the total world energy consumption is around 2^17TWh per year, so that's something like four years of energy (not even only power) used by people in the world. - V --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDnznAAoJEHvRgyDerfoR0gcQAJTRt8TdgvUW9SBJIVRU8qTR /LDJ8I0EXpFkMHcneW8+4yqEMJwa3EmWq3g+IZbd/LJf6yf4jAE8jCYQatmXRRq4 8F9Y8MuyVD3hKXyVs5w/9tvkmxgKJBoE0cGforTIg52B/FmR1ypAFaCGdM2PZXTF pJTs1AxQYaFyOQEyyQCIA0U4JkHEbvQIkS9OKl6ZGfFvHiCqDVW3BeIZAlWcF2BQ Pqv3wy6b/J0oiziCRClfi7i7zlbQKkP9XSGV3vxpZ0eK2rRjgFZ2fz7PQu2hhWsw n4PhGteJ2elT0jgxY7DQxg9WwtX3Yq6KCrvCrdzUhES3pYcNw7ljUvad8LJmXXGr xrzXxkc4RTJ1XMafILgcuvSpvJpru0ihYw5LiE9Q13a5LFkwtsRJdYLUAjekP5ET 88ryiyVB/Cj3HqvedL4TxfGdgP/jtAJ7vDgvN5jU9yQDaiCz6MniwwRehMJ2fd+e BkBQt16HgsSkL7j/spqUYuS3jO0X3leFvMbAAb6Lwi/WyXktPbwJPJogXJPaBqTB PuxKSEzVdjz5dDU/wJuO3oZ+92RRbPvQcechE+fVaJxF8rXz+t9LsDzP62RstjZa ti+qkR3wBqg2KoM9PRp6EOQ9pE6pO932c5zTOpmbjmtIP9/fpWXdRiwEd+rShjDC I7uHyzY6l6gmiCfjUi8y =oLS6 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From nobody Wed Apr 13 10:19:31 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0466512B029 for ; Wed, 13 Apr 2016 10:19:29 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnBMBcjwy-3i for ; Wed, 13 Apr 2016 10:19:26 -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 8A7F012D57F for ; Wed, 13 Apr 2016 10:19:26 -0700 (PDT) Received: from localhost (dhcp183-119.wlan.rz.tu-bs.de [134.169.183.119]) by mail.mugenguild.com (Postfix) with ESMTPSA id 959265FB6A; Wed, 13 Apr 2016 19:19:24 +0200 (CEST) Date: Wed, 13 Apr 2016 19:19:22 +0200 From: Vincent Breitmoser To: Ruben Pollan Message-ID: <20160413171922.GB4283@littlepip.fritz.box> References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> <146047167027.5102.16171502176440717800@KingMob> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <146047167027.5102.16171502176440717800@KingMob> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Simon Josefsson , IETF OpenPGP , openpgp-email Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 17:19:29 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ruben Pollan(meskio@sindominio.net)@Tue, Apr 12, 2016 at 04:34:30PM +0200: > In bitmask we do some of the things you propose Vincent. We attach public= keys=20 > to all sent emails until we get an email encrypted to this public key. We= attach=20 > the key as a mime part, because enigmail already have support for that an= d is=20 > one click to import it in your keyring. That's nice for interoperability but is also, imo, simply one click too much. > We also add the OpenPGP header to all the sent emails and use it to disco= ver=20 > keys from the 'url' field if it's https and from the same domain than the= email=20 > address. I don't think the URI field can gain any reach as long as it has to rely on users manually uploading the key somewhere. If an email provider did provided this service and added the header, that might work... but then the DANE approach probably works better for that scenario. > We need to be able to revoke, extend expiration, rotate subkeys, ... Timed updates from keyservers aren't as affected by the the connectivity, delay, and privacy problem as on-the-fly lookup while reading mail. - V --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXDn+aAAoJEHvRgyDerfoR9CkP/RkWtvINsdde4/tfWrHtH2sq kqBw2gdN2Cr1XILi7EmR4lJmoeGJ1/rDUUQLMAWj8KDSedt3sssC1t+B4lIeNdI7 tPaYIt1WbJiErf/9Dyj2Kk1dx+xBvhCWDY1BSI2RHZvOqUrSLCuwslxQt/fPC3yr 4AjkQGiAbR+7U9xWHZ+v3X2nM5TzCbg85ZvkH3H6PLdErrB/4fINyXesxmxuTWWV zu+k7w1Byghh+/QxxIJKYxPTf8RGWxdRobop0uhcUQfijDJjmU5YvAfHt731P4oW gKN1kHw9gROJvGkRR5mSbHQFbfNI5b4OCZ/3dKkCazDGZDhuoC+o3U77XovcIDr9 oGra10nUdrlUR4btgjJiysTnxkxnN9B0AYHrDosWeocP8zwnlsCUqNUHBSI5N9HH jFPt6lN+CetZIkT4PKt81WpFNcpprGK/wOuLVk4lND/s8panDTgegCwEi4OxLJRg /q/ebDOeEhGKGKAo3LqQjIv1zg5zE++NWittcqxxExilZuXbYm/Zsj+Cu3MpV3+J RNekmaY+gZIf1F31BF/br82LhUueJ2nzmkQhNAkD1lkZwp3Aku+L2zP8jlwXJW/V NU5OyTvtJP5u3m0J26xOu+MDYuketrsLuE0YF1x82iKH/u49oX2mPQ//LNDErMYg de4jkyEDK/ZYzef89GzN =9w49 -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From nobody Wed Apr 13 14:54:21 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84EB12DFDA for ; Wed, 13 Apr 2016 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va2J3L6x4uG8 for ; Wed, 13 Apr 2016 14:54:16 -0700 (PDT) Received: from eternauta.sindominio.net (eternauta.sindominio.net [80.81.122.47]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF8D12DFBE for ; Wed, 13 Apr 2016 14:54:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by lesnaus.sindominio.net (Postfix) with ESMTP id A6AC3403C75; Wed, 13 Apr 2016 23:54:13 +0200 (CEST) Received: from eternauta.sindominio.net ([127.0.0.1]) by localhost (lesnaus.sindominio.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqxXnnlB3MLi; Wed, 13 Apr 2016 23:54:10 +0200 (CEST) Received: from localhost (unknown [95.63.56.146]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by lesnaus.sindominio.net (Postfix) with ESMTPSA id B016B403C51; Wed, 13 Apr 2016 23:54:09 +0200 (CEST) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="===============6280268847554879418==" MIME-Version: 1.0 Content-Disposition: inline To: Vincent Breitmoser , From: Ruben Pollan In-Reply-To: <20160413171922.GB4283@littlepip.fritz.box> References: <20160412121549.GB16775@littlepip.fritz.box> <20160412154918.1ca8da7c@latte.josefsson.org> <146047167027.5102.16171502176440717800@KingMob> <20160413171922.GB4283@littlepip.fritz.box> Message-ID: <146058444780.3366.15556575961859224432@KingMob> Date: Wed, 13 Apr 2016 23:54:07 +0200 Archived-At: Cc: Simon Josefsson , IETF OpenPGP , openpgp-email Subject: Re: [openpgp] [openpgp-email] Keyserverless Use of OpenPGP in Email X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:54:19 -0000 --===============6280268847554879418== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Quoting Vincent Breitmoser (2016-04-13 19:19:22) > Ruben Pollan(meskio@sindominio.net)@Tue, Apr 12, 2016 at 04:34:30PM +0200: > > In bitmask we do some of the things you propose Vincent. We attach publ= ic keys = > > to all sent emails until we get an email encrypted to this public key. = We attach = > > the key as a mime part, because enigmail already have support for that = and is = > > one click to import it in your keyring. > = > That's nice for interoperability but is also, imo, simply one click too > much. Yes, that is why we automate the key fetch from this attachments and there = is no = user action involved. > > We also add the OpenPGP header to all the sent emails and use it to dis= cover = > > keys from the 'url' field if it's https and from the same domain than t= he = > > email address. > = > I don't think the URI field can gain any reach as long as it has to rely > on users manually uploading the key somewhere. If an email provider did > provided this service and added the header, that might work... but then > the DANE approach probably works better for that scenario. If I understood correctly DANE your are making public the list of all the e= mail = addresses (with OpenPGP keys) in your provider. I'm not sure how much I lik= e = that. But it's probably not worst that uploading the keys to the key server= s = anyway. We do upload the keys to the provider automatically and publish them in a = normalized url. > > We need to be able to revoke, extend expiration, rotate subkeys, ... > = > Timed updates from keyservers aren't as affected by the the > connectivity, delay, and privacy problem as on-the-fly lookup while > reading mail. Agree :) -- = Ruben Pollan | http://meskio.net/ -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D- My contact info: http://meskio.net/crypto.txt -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D- Nos vamos a Croatan. --===============6280268847554879418== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Description: signature Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXDr/+AAoJECy5AH9CUIqHJaIP/juj2PNmsENkrm8lQ32phvZ+ Y97BhQgYx1p2zcB25K1G3xO4hGoY4O/BegLaDm2pE3ABy6CbdPJsPBHaqqtKJ01F RzSAPi4DNOUfO2EvOeJkU2tSvyndN+PKC57Vk0HWVR94U61/Fq1g8vOa+V6Jlnh+ dGre0cZw+7JmzKO5kUc2767wYG1ogDMaQn/bfnfIyeJtftr6IeJuKQZ5cO9oFyDN UJv5sUo2ZAupd1jRj8Ek9PLjbko8jVkShlF920NXVdyVRT/YmxPPjXYUoXCj9VeM zp6kwVio2KzwrzLI0MeCHCMbNV49SMekLhEIAae64Rxx44wBh2RDXQnc5BM2NyEl ZBUkdp0gKm7Jl1vpiPcXQ+vz6jv6GBLopomSy/6S4PGpzrrqxSn+/rxRK/RjqYZw 4kYtFsLNGQnFzeN3kH5nhkgDHaSPu7H4QMHxWV9AsX1Tm7IFHcJc42EwMpvpfDJG gA0vOD2fQW9nwMzlmggJfTw4s6XvLWk/d7CHAfZbBAUeg87mg0H2nUxSyv48CTA3 qVaahIkD9Qdth0q221wtFrQzxAmu27I8O6fEBTZDsjVvtk7Muqpn7QpU4CfYsF4D LVrsyg0NemJIc5R7zMk4PdEAsgxt2z4dEtgZVQLZXT/YQUfZKQzJjrYRgB6o0F3a MnAFzMYQLSmv3mk/WTUj =V7mf -----END PGP SIGNATURE----- --===============6280268847554879418==-- From nobody Wed Apr 13 16:42:06 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5B12DA74 for ; Wed, 13 Apr 2016 16:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oih9UMXQNOMa for ; Wed, 13 Apr 2016 16:42:03 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 6406712D9D5 for ; Wed, 13 Apr 2016 16:42:03 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id k1so90599055vkb.0 for ; Wed, 13 Apr 2016 16:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sETRUc0CCSkp8U0wXBsK5YxUzO60xB/sokf46JqY1fk=; b=da0T4Z6eV4OkoGVnO0C7BMAST039l+woHdaV0PczW6DAPOzXXCg5mRifg9ieq6qH2q 7gTpOrO3V9CkiLlRDKXSUSq7GKtxiWCX2crKVIcRADPrx8s/02iikjtiXZMzbV3hOnZ5 bJB4D656hYo3w8XSgtK2yxfI5Ipjyz2lAUsqM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sETRUc0CCSkp8U0wXBsK5YxUzO60xB/sokf46JqY1fk=; b=LQLkahRR6bD6+KMu1aZdMa9jISPOvyY0xbWqy7f1yMtZ/KAM9DpjYJ7NeabI+BpEv2 7kMWNSU9P9RpY5u5lAEYtSqM15OvfnTR5c69j00F0mtxq2nQ8jKbWnVzwHp5LTCitrK2 EN4tSvbcXD5WAlmSN2FVIwDQj9TwVYXG7UxRKMW4vXN3A+05rvU0XLe6X1jp7zLzmZjh xJ6UXPXDfYuMZBdkPIYQ01pmCcYmwOuPsLTtaiHrELnW2j0Ohk5rRePZ7VuSzvchPOGv FwJTt3B2RwihMvpJBxaWgJxAO7yCMkqitPNZrTv+Auj83SeT/yj5mBkqEeQYzHIQvmru ujow== X-Gm-Message-State: AOPr4FWSft5ne8yqFC6fBVyg3BksXl2C8ErtPzG1GrIY7V/CWj2XMc4ybmAFyrDTUgU7ArWqAGUlBbSys9K5qJuL MIME-Version: 1.0 X-Received: by 10.159.33.183 with SMTP id 52mr5335753uac.114.1460590922311; Wed, 13 Apr 2016 16:42:02 -0700 (PDT) Received: by 10.103.94.3 with HTTP; Wed, 13 Apr 2016 16:42:02 -0700 (PDT) In-Reply-To: <20160413170751.GA4283@littlepip.fritz.box> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net> <20160412172246.GE9034@hashbang.sh> <20160413170751.GA4283@littlepip.fritz.box> Date: Wed, 13 Apr 2016 19:42:02 -0400 Message-ID: From: Joseph Lorenzo Hall To: Vincent Breitmoser Content-Type: multipart/alternative; boundary=001a113acfc21650bc0530665370 Archived-At: Cc: IETF OpenPGP , KellerFuchs , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 23:42:05 -0000 --001a113acfc21650bc0530665370 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable that is pretty damn convincing to me, thanks On Wednesday, April 13, 2016, Vincent Breitmoser wrote: > > usually considered =E2=80=9Cbroken=E2=80=9D by cryptographers > > This is not the general case cryptographers talk about, but a specific > use case with a very specific set of requirements. > > > so it seems OK to be somewhat cautious here and require collisions > > to be hard. > > If we could get it for free, maybe. But collision resistance is a factor > two in bitsize, which is not only not free, but pretty darn costly. > > Just to get a feeling for the numbers, let's do some good old > pessimistic math: > > We take a 128 bit fingerprint. We say the attacker wants to attack a > pool of 65000 keys, so 2^16. That leaves 112 bits of fingerprint to > attack. We also assume that an attacker can test as fast as they can > generate sha-256 hashes, and give no penalties for key generation, > multi-target attack, collisions or stuff like that. > > Top of the line hashing ASICs are at about 5 terahashes per second. But > let's just say our attacker has 10 terahashes/s (2^43) per device for > ease of math. Then let's say our attacker has one *billion* of those > devices (2^30), which is a ridunculous number to have. > > In this scenario, our attacker needs 2^(128-16-43-30) =3D 2^39 seconds to > find a single preimage, which is 17432 years. > > From a different angle, for one Joule of energy (=3D 1 watt-second) you > can very optimistically get about 5T (2^42) sha256 hashes for one Joule > of energy. For 2^112 hashes, that's 2^(112-42) =3D 2^70 Joule of energy, > or 2^19 terawatt-hours of energy. For comparison, the total world energy > consumption is around 2^17TWh per year, so that's something like four > years of energy (not even only power) used by people in the world. > > - V > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --001a113acfc21650bc0530665370 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable that is pretty damn convincing to me, thanks

On Wednesd= ay, April 13, 2016, Vincent Breitmoser <look@my.amazin.horse> wrote:<= br>
>=C2=A0 =C2=A0usually considered =E2= =80=9Cbroken=E2=80=9D by cryptographers

This is not the general case cryptographers talk about, but a specific
use case with a very specific set of requirements.

>=C2=A0 =C2=A0so it seems OK to be somewhat cautious here and require co= llisions
>=C2=A0 =C2=A0to be hard.

If we could get it for free, maybe. But collision resistance is a factor two in bitsize, which is not only not free, but pretty darn costly.

Just to get a feeling for the numbers, let's do some good old
pessimistic math:

We take a 128 bit fingerprint. We say the attacker wants to attack a
pool of 65000 keys, so 2^16. That leaves 112 bits of fingerprint to
attack. We also assume that an attacker can test as fast as they can
generate sha-256 hashes, and give no penalties for key generation,
multi-target attack, collisions or stuff like that.

Top of the line hashing ASICs are at about 5 terahashes per second. But
let's just say our attacker has 10 terahashes/s (2^43) per device for ease of math. Then let's say our attacker has one *billion* of those devices (2^30), which is a ridunculous number to have.

In this scenario, our attacker needs 2^(128-16-43-30) =3D 2^39 seconds to find a single preimage, which is 17432 years.

>From a different angle, for one Joule of energy (=3D 1 watt-second) you
can very optimistically get about 5T (2^42) sha256 hashes for one Joule
of energy. For 2^112 hashes, that's 2^(112-42) =3D 2^70 Joule of energy= ,
or 2^19 terawatt-hours of energy. For comparison, the total world energy consumption is around 2^17TWh per year, so that's something like four years of energy (not even only power) used by people in the world.

=C2=A0- V


--
Joseph Lorenzo Hall
Chief Technologist, Cent= er for Democracy & Technology [https://www.cdt.org]
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871
--001a113acfc21650bc0530665370-- From nobody Thu Apr 14 08:18:15 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE36112D717 for ; Thu, 14 Apr 2016 08:18:12 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUgaNa6n-VhL for ; Thu, 14 Apr 2016 08:18:06 -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 6E12512E0FB for ; Thu, 14 Apr 2016 08:18:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8D64FE2038; Thu, 14 Apr 2016 11:18:04 -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 05784-06; Thu, 14 Apr 2016 11:18:00 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 78E04E2030; Thu, 14 Apr 2016 11:18:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460647080; bh=NkeW8GQHdLaVyQiAFeyAlO8lXDZNSlfxzKZP8Ysq/Q0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=jT97bEGjF8WskWA3N9lvRrwvZDBKzJ9uhlYY2R68vGyt7VrXYDnXhfrMuaKRJKqZQ u0/9sL5RHNltaVOvnW71DAehH4A2K9PY0L0aaILVS7VlVfYHWPhrYyfFw+tzo769HL Pha1jV8ab6IkhlXlfVN1zHd/bTa2ijUU15dVHBC8= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3EFHrvP011295; Thu, 14 Apr 2016 11:17:53 -0400 From: Derek Atkins To: Derek Atkins References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87d1pug303.fsf@wheatstone.g10code.de> <85d83d5bac518c53d7a78d5d049a73ed.squirrel@mail2.ihtfp.org> <87wpo2ehch.fsf@wheatstone.g10code.de> <87zisxa4ac.fsf@wheatstone.g10code.de> Date: Thu, 14 Apr 2016 11:17:48 -0400 In-Reply-To: <87zisxa4ac.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 13 Apr 2016 17:59:07 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:18:13 -0000 Werner Koch writes: >> I think we need to step back again and keep in mind that the (human) >> authenticaton fingerprint may (should?) be different from the (internal >> or external) database identifer string. > > Okay. But the new scheme should allow to derive the human > authentication fingerprint from the internal fingerprint w/o the need > for additional input. Well, this then begs the question of whether this internal fingerprint may include additional information or if it's purely on the actual key material. I've lost the mental context for the argument that the identifier should be on the actual public key and not the "key certificate". Provided that the fingerprint is over the "public key certificate" (i.e., public key parameters plus some additional data such as creation and expiration times) I have no objection to the "human authentication fingerprint" being derived from that. > Shalom-Salam, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 14 08:21:33 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB32912E47C for ; Thu, 14 Apr 2016 08:21:32 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApZgEqctGtuQ for ; Thu, 14 Apr 2016 08:21:31 -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 0C36212E47A for ; Thu, 14 Apr 2016 08:21:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9A93EE2036; Thu, 14 Apr 2016 11:20:58 -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 05837-05; Thu, 14 Apr 2016 11:20:54 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 DF579E2030; Thu, 14 Apr 2016 11:20:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1460647254; bh=W4VrwUcDlnWBMbCn0THBy5iiBg7ptJ2+817Qhl0xt1E=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=LIYKeGrz2M3Omoxd/fpdHQbZL2KeBwbtlCS8DzNzxLQlVH+YRW6B/JUOYZgY12MYH K+ycnFvpRq6ue41AZ7mNG+B3KMNnmaWgT0NxmcaRFOMTmZgjEgpBpmKYYVJOs+c3Np HBSYH+Ni5IL/NFSsHZMczk6/wu4uzqVc/OeiYYVw= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3EFKn3s011456; Thu, 14 Apr 2016 11:20:49 -0400 From: Derek Atkins To: Joseph Lorenzo Hall References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <20160412131545.GA20078@littlepip.fritz.box> Date: Thu, 14 Apr 2016 11:20:49 -0400 In-Reply-To: (Joseph Lorenzo Hall's message of "Wed, 13 Apr 2016 11:23:44 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:21:33 -0000 Joseph Lorenzo Hall writes: > On Tue, Apr 12, 2016 at 9:15 AM, Vincent Breitmoser > wrote: >> Joseph Lorenzo Hall(joe@cdt.org)@Tue, Apr 12, 2016 at 09:06:11AM -0400: >>> If you have two keys that map to the same fingerprint, then an >>> attacker can decide to serve you whichever is in their best interest. >> >> The premise of your scenario is that you are already using a key >> generated by the attacker. What could an attacker possibly gain by >> possessing a second key with the same fingerprint? > > Sorry so slow to respond... my premise is that increasingly I query > for full fprs to obain keys from keyservers and if that maps onto two > different keys with the same UserID that would be bad. > > I guess what the rest of the thread here is saying is that it would be > so computationally difficult for a malicious keyserver to find a > collision that this isn't a problem. That's not a collision, that's a preimage attack. A collision is where Eve generates a pair of keys together with the same fingerprint, but doesn't care what that key/fingerprint is -- only that they are the same. A preimage attack is where you're trying to find a key that matches a specific (existing) fingerprint. That's a MUCH harder attack. So yes, it would be extremely difficult for Eve to generate a key with the same fingerprint as Alice's key. > (apologies for being somewhat dense) -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 14 09:40:13 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6212E132 for ; Thu, 14 Apr 2016 09:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj5BEEF_jS8f for ; Thu, 14 Apr 2016 09:40:07 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 8700A12D97B for ; Thu, 14 Apr 2016 09:40:07 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id c4so116310053vkb.3 for ; Thu, 14 Apr 2016 09:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4lWcZgzKLmbMPC80GQHSFrAUmbWmnm+OJG6vujiZLAU=; b=Cxmw7CtqqP0/rOfDuj77n5Cv4UqcceK1gCtw70LDgHmqyuYBpP3eiAbQwTxdh4B9tE P/0xG3e6N9sjFth8hb+pwm1VkXcvb5ZZdEKM6+5QxBJE2iHh2GBdAHz6t8QDjjX/QkQN Y0mR2sOh7YcMziu+LX87pRb5Cw3zkdInN5p90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4lWcZgzKLmbMPC80GQHSFrAUmbWmnm+OJG6vujiZLAU=; b=fK/yTCEx01lnKaWzAZfPABfOuuuTQgq572PtBeVUK7gsFJ4vGML7xnDaaDxzTGlKn0 2AoZv7vZ1KKLyUTt5aZ1UCpKCa2vPA/Pfi7YO8TaH89AVCbB+g17HstxneZVZhFzKlcu VpDkbFFhjGjwTU6Dyc1lXJSQpJ5bLUTCvdjlxPbkgdaPQth0+S6KoJ3+xz6Ur3xQHasP /DzugpBTv9yCcL0oYIOkbcOWR5UKL9UIfRNJ1KcYEEGuwv3Y0p2ATfn/17zOtlfM00Lu pwElEMHHgTlbTARRrlOeQ02ujwSW0aAKrZcRQDBg3WV8/7FEpLQ1n1/nGZY9zSCMCdQe ldjQ== X-Gm-Message-State: AOPr4FUbO6t4YI9p5bBJQzbgkaFlIrJRje103P0utiMrWzE4a+RlEHcHF8KBbBRFNAi/30/HPw9g8bobCQ4bWPCs X-Received: by 10.31.47.135 with SMTP id v129mr8046911vkv.115.1460652006115; Thu, 14 Apr 2016 09:40:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.94.3 with HTTP; Thu, 14 Apr 2016 09:39:46 -0700 (PDT) In-Reply-To: References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <20160412131545.GA20078@littlepip.fritz.box> From: Joseph Lorenzo Hall Date: Thu, 14 Apr 2016 12:39:46 -0400 Message-ID: To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 16:40:11 -0000 On Thu, Apr 14, 2016 at 11:20 AM, Derek Atkins wrote: > Joseph Lorenzo Hall writes: > >> On Tue, Apr 12, 2016 at 9:15 AM, Vincent Breitmoser >> wrote: >>> Joseph Lorenzo Hall(joe@cdt.org)@Tue, Apr 12, 2016 at 09:06:11AM -0400: >>>> If you have two keys that map to the same fingerprint, then an >>>> attacker can decide to serve you whichever is in their best interest. >>> >>> The premise of your scenario is that you are already using a key >>> generated by the attacker. What could an attacker possibly gain by >>> possessing a second key with the same fingerprint? >> >> Sorry so slow to respond... my premise is that increasingly I query >> for full fprs to obain keys from keyservers and if that maps onto two >> different keys with the same UserID that would be bad. >> >> I guess what the rest of the thread here is saying is that it would be >> so computationally difficult for a malicious keyserver to find a >> collision that this isn't a problem. > > That's not a collision, that's a preimage attack. > > A collision is where Eve generates a pair of keys together with the same > fingerprint, but doesn't care what that key/fingerprint is -- only that > they are the same. A preimage attack is where you're trying to find a > key that matches a specific (existing) fingerprint. That's a MUCH > harder attack. > > So yes, it would be extremely difficult for Eve to generate a key with > the same fingerprint as Alice's key. Thanks for this, and for putting up with my relatively cryptographic naivete for this WG! best, Joe -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Thu Apr 14 12:29:59 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6712DA49 for ; Thu, 14 Apr 2016 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE1U0wy0ffZ5 for ; Thu, 14 Apr 2016 12:29:56 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 4B2C312D6B9 for ; Thu, 14 Apr 2016 12:29:56 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id fs9so28789168pac.2 for ; Thu, 14 Apr 2016 12:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version; bh=agHlianYXDAIB2Euqd2Poko4PnX6gvfyYiR1Yk5iWo8=; b=fuhzt4ubak5nfrqJLJRxri4HqSHRi8bxxWOIS/TDewqrDrzygzPc7+GtqfWRTs7mEY 15IpJyhG6IPaeOIn4qM+udcWHsgvczg7FxJtRFevIWC4Cj7LNNF4ayeEbn6eFuFveJh0 dO2yudCZrW+Ve/1oO4wNLHja2hdrwiTBQ0x3Q28XwmWZJEkZHcp3MEGLV6V6/Ca/xl3E Q+Ndl5BwTs7Ai8BeFXmrVfuYu8q2QJ1Jzt7PCqnURFvHCyjNuOjhgYGY8NM2gooXtjqa vhZMDd/b7xQwSA6pbg58RJZvSDjc7T+IQ4RRW/MKlNc+cnYgBj5a86HKPt+8VHwGT30r VuDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:message-id:in-reply-to :references:subject:mime-version; bh=agHlianYXDAIB2Euqd2Poko4PnX6gvfyYiR1Yk5iWo8=; b=XKyBrShjwFSWT+zQgBbPX0vKETXwadiZ15afD1ByB6h+oE/TSJHAzShE57zHGjR1h0 PB1qwwOJUX7VpMVZXvcAPOy16j1eWiWXDCbV8hnRVFmzNJlrzaSRVCt5sXsPqfOIvx9r v2t+N/G40sQDcxwPWtEwrmvQAj9gho/IVilSKeOKnNHah6sq0PWshVB7IqM7E4mB9+fq 98XC2yDCWaRsG9m2ekBDEgF8JbDG3/6aTIuArr6Z8ETuWnYUgSJyFQH3+leRo9atxEXI 5LJQ+Ez/WXs5KBYESaUIWUQjYMlH2aJwuKibNmuZL2hvE5vgfrfgubZG9xzFxJTCesmY lRFw== X-Gm-Message-State: AOPr4FVitoUoGZ7j9BQ7C6UIgqF//veF+3BTUnffeZj+opiTmXU2gbfhAFGrbBGZLAbU5A== X-Received: by 10.66.139.9 with SMTP id qu9mr23762330pab.101.1460662195896; Thu, 14 Apr 2016 12:29:55 -0700 (PDT) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id ch2sm59791011pad.28.2016.04.14.12.29.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 12:29:53 -0700 (PDT) Sender: Phillip Hallam-Baker Date: Thu, 14 Apr 2016 19:29:52 +0000 (UTC) From: Phillip Hallam-Baker To: Bill Frantz , IETF OpenPGP Message-ID: <994C5976EA09B556.C7F805B4-A4A2-4B9D-827C-A320136C493A@mail.outlook.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6846_1199658313.1460662192254" X-Mailer: Outlook for iOS and Android Archived-At: Subject: Re: [openpgp] Fingerprint requirements for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:29:58 -0000 ------=_Part_6846_1199658313.1460662192254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sent from Outlook Mobile _____________________________ From: Bill Frantz Sent: Tuesday, April 12, 2016 9:01 PM Subject: Re: [openpgp] Fingerprint requirements for OpenPGP To: IETF OpenPGP I have not heard anyone arguing that we don't need some form of=20 fingerprint that can be typed into a computer for comparison.=20 (Several have argued that eyeball comparison is error prone.) Well, typing random data is error prone too. Perhaps we should=20 have some form of check digit(s) so the program processing the=20 type in can flag bad data entry and not confuse it with=20 fingerprint match failure. Cheers - Bill -------------------------------------------------------------- There are many use cases for typing in a fingerprint. I want to send someon= e a mail, I read their fingerprint off a business card or they read it over= the phone or I cut n'paste from somewhere.Comparison is more common though= . And that allow us to use 'big dictionary' type approaches. I am working on a doc, but there are some important points from the WG meet= ing. One is that there seems to be a confusion between whether the fingerpr= int or the key is a root of trust.=C2=A0If you think it is the key that is = the root of trust then the fingerprint has to be canonical, must not includ= e a date stamp (like it does at present). If however you regard the fingerp= rint of the key as the root of trust then it does not need to be canonical.= Invalidating a key in one context does not necessitate invalidating it in = all contexts. The catch being that when the key is presented for validation= , you have to also present all the original attributes bound to it. =20 ------=_Part_6846_1199658313.1460662192254 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
_____________________________
From: Bill = Frantz <frantz@pwpconsult.com>
Sent: Tuesday, April 12= , 2016 9:01 PM
Subject: Re: [openpgp] Fingerprint requirements for OpenP= GP
To: IETF OpenPGP <openpgp@ietf.org>


I have no= t heard anyone arguing that we don't need some form of
fingerprint that= can be typed into a computer for comparison.
(Several have argued that= eyeball comparison is error prone.)

Well, typing random data is err= or prone too. Perhaps we should
have some form of check digit(s) so the= program processing the
type in can flag bad data entry and not confuse= it with
fingerprint match failure.

Cheers - Bill

-------= -------------------------------------------------------

There are many use cases for typing in a fingerprint. = I want to send someone a mail, I read their fingerprint off a business card= or they read it over the phone or I cut n'paste from somewhere.
Comparison is more common though. And that allow us t= o use 'big dictionary' type approaches.
I am working on a doc, but there are some= important points from the WG meeting. One is that there seems to be a conf= usion between whether the fingerprint or the key is a root of trust. <= /div>
If you think it is the key that is the root= of trust then the fingerprint has to be canonical, must not include a date= stamp (like it does at present). If however you regard the fingerprint of = the key as the root of trust then it does not need to be canonical. Invalid= ating a key in one context does not necessitate invalidating it in all cont= exts. The catch being that when the key is presented for validation, you ha= ve to also present all the original attributes bound to it.
=20 ------=_Part_6846_1199658313.1460662192254-- From nobody Thu Apr 14 13:14:13 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5D312DF09 for ; Thu, 14 Apr 2016 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59GyiE2kqrM3 for ; Thu, 14 Apr 2016 13:14:09 -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 BD24B12DE3E for ; Thu, 14 Apr 2016 13:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 177ECE2036; Thu, 14 Apr 2016 16:13:32 -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 07811-04; Thu, 14 Apr 2016 16:13:28 -0400 (EDT) Received: from securerf.ihtfp.org (tacc-24-54-172-229.smartcity.com [24.54.172.229]) (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 2D425E2030; Thu, 14 Apr 2016 16:13:23 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u3EKC4DG028654; Thu, 14 Apr 2016 16:12:04 -0400 From: Derek Atkins To: Werner Koch Date: Thu, 14 Apr 2016 16:12:03 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:14:12 -0000 --=-=-= Content-Type: text/plain Hi, The attached patch to RFC4880bis reserves two public-key parameters. They are specified as "reserved" and I've added text to 13.8 as well documenting that they are underspecified. Note that these are NOT "MTI" algorithms in any way, shape, or form! Thanks, -derek --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=rfc4880bis-aedh.diff Content-Description: Add AEDH and AEDSA >From b2ffaf54bac27ed59a836e0588cfed8d0097d584 Mon Sep 17 00:00:00 2001 From: Derek Atkins Date: Thu, 14 Apr 2016 16:06:49 -0400 Subject: [PATCH] Add AEDH and AEDSA protocol number reservations --- middle.mkd | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/middle.mkd b/middle.mkd index 033f11f..0fa9efd 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2890,6 +2890,8 @@ algorithms. 21 Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 22 EdDSA [](#I-D.irtf-cfrg-eddsa) + 23 Reserved for AEDH + 24 Reserved for AEDSA 100--110 Private/Experimental algorithm Implementations MUST implement DSA and ECDSA for signatures, and @@ -3182,6 +3184,8 @@ This document requests IANA register the following public-key algorithm: ID Algorithm Reference -- -------------------------- --------- 22 EdDSA public key algorithm This doc + 23 Reserved for AEDH This doc + 24 Reserved for AEDSA This doc [Notes to RFC-Editor: Please remove the table above on publication. It is desirable not to reuse old or reserved algorithms because @@ -3950,7 +3954,9 @@ algorithm. These are marked in Section 9.1, "Public-Key Algorithms", as "reserved for". The reserved public-key algorithm X9.42 (21) does not have the -necessary parameters, parameter order, or semantics defined. +necessary parameters, parameter order, or semantics defined. The same +is currently true for reserved public-key algorithms AEDH (23) and +AEDSA (24). Previous versions of OpenPGP permitted Elgamal [](#ELGAMAL) signatures with a public-key identifier of 20. These are no longer permitted. An -- 2.5.0 --=-=-= Content-Type: text/plain -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From nobody Sat Apr 16 08:56:27 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B2912D7B0 for ; Sat, 16 Apr 2016 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx_9nLTOiDRC for ; Sat, 16 Apr 2016 08:56:24 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 C830212D663 for ; Sat, 16 Apr 2016 08:56:23 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id e190so175801818lfe.0 for ; Sat, 16 Apr 2016 08:56:23 -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; bh=Kyx68Uv7o+kAENhsRRwlQMe9jEqWxKzIQO/6iZSoOt0=; b=jr0i280xy9xC+3nXQaEln/wIemqj9t/PRSGs0iZesjXgfVIz1O6nH+J6Qmr8W4OfYg vWvoFM5thX5sUXlwP96SPjyFNZ2RNOfhW6OLx9M5ymP3wrrGrYR9R4jitRFP9gnCIOaK 97kKOwjIutLWFJIOSiQDYQm/kG9NMEKTo223V9xjopwYs0m1JSaOcn18U5oVF0QAq+j0 sqgCqgJRUo6rpKdnG8WKpSP3G8z9Yo3NUXfC4Mbwo6qIS06k9AsuGgLoTW1DiZdV4dcl HH6JX5DPPdLjvs+ugdR7eVQUDrv8xzatHDpTA/mYsQxrO90Am47zp93GD+L80s2EjDxV 6Njg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Kyx68Uv7o+kAENhsRRwlQMe9jEqWxKzIQO/6iZSoOt0=; b=gZRensvFr4xlVEsRD78ijOB5kTwvbYHuyvEs51/kfQ10z/xNlcDD2Ap+eaF3KGY7Lf ND5U8mg+f4t1DQ4yCbZziM/cN+PuY4tYM4vRNWRSdJLv/EslpfusXTH/vAdX7nptnwl/ 1kI8HKEirDXtOUSZFhbSJksNOtKtT9nmrklbVo5K/VAbFnyKUTHyAruzt6ugNPJ5FBNf qAzSmosjEPXbU70e0hE9Tg67KKR/EfBOyVqY5U7e2moRGj3ivOidQ4EaaKrg2qYOmCMW FLbGg1epf5Ic2MJS0Yo/3AleLSn9AZchIW/nu6O3qfcoUfJq2CvgxtX1e6CXEi6I5vku z2cw== X-Gm-Message-State: AOPr4FWkOb0KjDqUeGEHMBGqwb9XuCF9PLBgDq3zWg9L8bvzjxbynd1NOP6SOi2zzY4CG2f+5lz0d0WyhAUc7g== MIME-Version: 1.0 X-Received: by 10.25.135.194 with SMTP id j185mr8454996lfd.39.1460822181887; Sat, 16 Apr 2016 08:56:21 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Sat, 16 Apr 2016 08:56:21 -0700 (PDT) In-Reply-To: <87potuadxq.fsf@alice.fifthhorseman.net> References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87potug3s5.fsf@wheatstone.g10code.de> <87potuadxq.fsf@alice.fifthhorseman.net> Date: Sat, 16 Apr 2016 11:56:21 -0400 X-Google-Sender-Auth: TxEn3B7CJKRZ40dDppY5Oqow7nE Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Werner Koch , IETF OpenPGP Subject: Re: [openpgp] proof-of-work fingerprints [was: Re: Fingerprint requirements for OpenPGP] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 15:56:26 -0000 This is almost the scheme I am looking at. The main practical difference is that I don't see the need to be quite so granular. If people are going to use proof of work, then I would start off with a threshold designed to take about an hour of processing on contemporary machines, for the sake of argument, say that is 24 bits. Then I would allow for prefixes of 24, 34, 40 bits. This approach can be encoded using a leading 1s approach. So each increase in work saves 7 bits. The increase in work may look dramatic, but it really isn't because I expect people would throw parallel machines at the problem. Also note moving from RSA to ECC saves a huge chunk of keygen time. So any compression scheme is having to deal with a vast difference in computing demands and capabilities. The wonderful thing about exponents is that they tend to quickly balance any mismatch in such things. The other trick I think is very useful is to use truncated fingerprints as keyIds. Lets say that we start with a SHA-51 On Tue, Apr 12, 2016 at 2:18 PM, Daniel Kahn Gillmor wrote: > On Tue 2016-04-12 13:01:14 -0400, Werner Koch wrote: >> According to Peter, this means SHA-256. There may be no proof-of-work >> to for creating a key and thus a structured fingerprint. (Sometimes you >> have to create a lot of one-off keys.) > > The one proposal i've heard that keeps things somewhat simple but still > allows the possibility of an increased cost to an adversary intent on a > preimage attack is related to floating point implementations, and was > suggested by PHB. I try to describe my understanding of the scheme > below, but writing it all down makes me think that "somewhat simple" > might be overselling it; there are quite a few complications. > > Here goes: > > * Start from a design of a fingerprint of X bits, using a truncation of > digest of size Z (where Z > X). for example, a 200-bit fingerprint > from sha-256. this would typically mean an adversary has to do about > 2^200 sha-256 operations to find a match. (this is an impossibly > high bar if we're talking about brute force, but if we assume that > most cryptanalysis of SHA-256 allows an attacker to shave off some > sizeable work factor, it represents the "safety margin" against > unknown cryptanalysis of this type) > > * Instead, make the fingerprint X+N bits, where the first N bits > indicate the number of leading zeros of the digest. Now if i do a > bit of work to generate keys with, say, 10 leading zeros, an attacker > will probably need to do about 2^10 more digests to find a match. > > So if we're doing a 200-bit truncation of sha-256, and we have an 8-bit > count of leading zeros, and the digest produced is (in hex -- i'm not > making an argument about choice of textual representation here, just > showing in hex for discussion): > > 001a1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2 > > then it would result in a fingerprint of (again in hex for discussion): > > 0ba1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da5 > > That is: 11 (0x0b) bits of zeros, followed by a 1 bit, followed by > a1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da5 > > More precisely, under this scheme, fingerprint generation looks like: > > scan1(x) : the position of the left-most 1 bit in bitstring x > A[n:m] : bits n through m-1 of bitstring A > enc(n,b) : a bitstring of length b encoding n as an unsigned int > dgst(x) : a fixed-length bitstring digest of bitstring x (e.g. sha-256) > X : number of explicitly-represented bits > N : size of bitfield for counting leading zeros > || : bitstring concatenation > > def fpr(z): > h = dgst(z) > k = scan1(z) > return enc(k,N) || h[z+1:z+1+X] > > * note that first bit that is set to 1 is omitted from the > representation (it's present by implication). This isn't just a hack > to squeeze one more bit of entropy out of the fingerprint, it's > arguably necessary to ensure that there is exactly one fingerprint > that corresponds to any given digest. Otherwise, i can represent a > fingerprint with 3 leading zero bits as: > > <3> 1100101... > > or: > > <2> 01100101... > > or: > > <1> 001100101... > > or: > > <0> 0001100101... > > The other alternative is to require that the leading bit after the > zero-run prefix is always 1 (unless the zero-run prefix is maxed > out?), which would mean that certain fingerprints are simply invalid > (we'd want tools to reject them?) > > * note also that for some choices of dgst and N it would mean there > could be some keys that are un-fingerprintable. For example, if we > chose dgst = sha-256 and N = 5, then any key that has a sha-256 > digest with a leading run of more than 31 zeros might be > unrepresentable. > > With all these caveats, i confess the much-simpler construction "200-bit > truncation of sha-256" looks pretty appealing :) > > --dkg > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sat Apr 16 09:58:04 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5412C12DF0D for ; Sat, 16 Apr 2016 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkXimWv4Itzk for ; Sat, 16 Apr 2016 09:58:00 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 8D75112DECE for ; Sat, 16 Apr 2016 09:57:59 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id j11so176431737lfb.1 for ; Sat, 16 Apr 2016 09:57:59 -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; bh=vBDaXBpDK19LIJLbBbdwIwB7UbM8RzYvq3muENIwUUQ=; b=wzyuewcVt4t6NCKY8PAiT+KrnrijO5GyTAeQ30fSe5NnV1R5jJpPFwbr3i9zEBY/hn j+ED5sH+krJyyZuMLXfmmasNZjAAJ/R1tfdBYmWfjG1/G3+8LdTTAtxf9Bb8jB5Sqjug bx78whFbkt8Ms61t0f5XA7UOddcZyd9KoFFGFjgpoLyaOosDyKqOut7Pd+DayKdHMUer CevRz1+HugtFjmVLWteqDquZOoBDYbVAWwpLoTQyYcgQ98VhkzXO0KpPB2RkYGvQsKr6 d2t24PpEgN3mcbvGYB2RW7paEsZO2bJPrftJCyeqXjvgMARtYNccSzsm1eSTywhNCc8r 0Qjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vBDaXBpDK19LIJLbBbdwIwB7UbM8RzYvq3muENIwUUQ=; b=PNje69q2shyzyxiL+j/yOKnC7DAXbmVNVCo44JUJipHYQJ+LpXE7bmUzDOB4nsQ5v9 8zmsMTWUWgMefnKf5PP3kW/r4jEf1eeOVPmIwy5Lnkex87oK/A3FFu4oxe0WB1wJgWtq 2M31CvUUt5lZqP3GAEYd5qJLdgYbHbT3bYw2pBM+619NB1Bac2fwM3pvE1lr2gK7mXOG IbqtcSHXvRfqCscPaBUMYnNV5uPZyJo9xmFQqFFz0yNlgAr8empzrAn7mLZXSxqGDqBC Ne6nEIjiZDWtZKmS/5amr9LTdJ33ZV38fFRmP1uAnbXnJcXCmrf3OBSQtjJMNuS3K+RL T2Pw== X-Gm-Message-State: AOPr4FVViMi2/o920q0xFCpc50UfNZz4DpedYRiL0z/5X/apFCzprvnomqTF2wpZ5jgG+MX47t5X7iqXMe8PSw== MIME-Version: 1.0 X-Received: by 10.25.209.73 with SMTP id i70mr2021851lfg.67.1460825877620; Sat, 16 Apr 2016 09:57:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Sat, 16 Apr 2016 09:57:57 -0700 (PDT) In-Reply-To: References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <87potug3s5.fsf@wheatstone.g10code.de> <87potuadxq.fsf@alice.fifthhorseman.net> Date: Sat, 16 Apr 2016 12:57:57 -0400 X-Google-Sender-Auth: TZwXYdJpwH87rY0Qawo851UsLqs Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Werner Koch , IETF OpenPGP Subject: Re: [openpgp] proof-of-work fingerprints [was: Re: Fingerprint requirements for OpenPGP] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 16:58:03 -0000 @#($*@#(!! Gmail sent the other one too soon. On truncation, there are some game we can play. Lets say that we start off with a 256 bit hash. Now I am only using SHA-2-512 and SHA-3-512 because I want to have as many rounds as possible even if I am going to discard bits I distinguish between the following 1) The hash output size (512 bits for UDF) 2) The fingerprint size (250 bits for UDF) 3) The presentation size (varies from 25 bits to 250 bits in 25 bit increments) So the has output is 512 random bits which give the following fingerprint: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J-C4OZQ-5GIN2-GQ7FQ-EEHFI This may be presented as phill-6DUF5@hallambaker MB2GK-6DUF5-YGYYL-JNY5E MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ ... MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J-C4OZQ-5GIN2-GQ7FQ-EEHFI Depending on the context. Now note here that I am assuming that users will be using subkeys and so in most contexts, a PGP fingerprint is of a key that under best practice is only ever used to sign other keys. The only case where it is not is when someone has already identified the signing key and is looking for the correct sub key for a specific operation. At the moment, a general overhaul of the OpenPGP key distribution system is out of scope. But it is my view that we should consider the possibilities for a new key distribution infrastructure when we design a new fingerprint scheme. Our choices here will open or close future options. In particular, I am assuming that there will be a convergence of the OpenPGP, SSH and S/MIME key distribution mechanisms (all suck today) and that this convergence will result in the emergence of a new infrastructure that looks somewhat like 'BaL's MIT key server plus blockchain'. This is what I am currently building in the Mesh. The idea is that the Mesh is a hash chain notarized, append-only log that can be written to from multiple input streams (portals) and finalizes every hour or so. So if you have that type of backing infrastructure, you can take a short presentation of a fingerprint, 'MB2GK-6DUF5-YGYYL-JNY5E' and consult the Mesh to receive back a record that gives you the corresponding public key record and the full length fingerprint. This allows me to make fingerprints really short since all that is necessary is to distinguish them in context. phill-6DUF5@hallambaker only needs a 25 bit fingerprint presentation because it is only necessary to distinguish the key from any prior keys for phill@hallambaker.com that have been checked in previously. [Yes, this uses the second block of the fingerprint. That is because the first block ends up filled with control information] This approach is similar to the 'last four digits' of your credit card number which is rather hilariously used as an abstract for the whole card number. It is hilarious because the first six digits are the bank identification number and there is one digit of checksum. Many small banks have less than 100,000 accounts and so they only actually use the last 6 digit fields. In our context, the approach is secure because people won't be creating a thousand fingerprints for their own use and expecting them to work. There are two considerations for fingerprint size 1) How many data items do we want to hash? 2) What is the work factor we want to set for breaking any one of them? When we are talking about OpenPGP fingerprints, I think the first number is about 2^40 the global population is roughly 8 billion (2^33) and a hundred trust roots per user seems enough for a lifetime. For work factor, the very lowest lower bound would be 2^85 right now which gives us a total work factor of 2^125 as the very lowest fingerprint size to be considered 'safe'. Using the 'work hardening' approach described in the earlier message, we can create a 100 bit signature that has a work factor of 2^125. Which is short enough to fit on a business card. There are many contexts where I would not want to do work hardening though. Particularly in an enterprise network where I am creating keys for individual devices. The considerations for sub keys are rather simpler as there we only need to consider how many keys the parent has signed. Lets say the sub key distinguisher is E34TG, we might represent that in a config file as follows: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ/E34TG Now all this is quite a bit more complex than OpenPGP alone needs or you are going to accept right now. But it is mechanism that delivers a lot of power and convenience if it can be applied to all a user's cryptographic applications. Wouldn't it be nice if you could cut and paste your single Mesh master key fingerprint into a PGP application, an SSH application and an S/MIME application and have them all 'just work'? Another game that can be played with master keys is the one I outlined in the Arcing BOF and I am writing up a paper on. A key fingerprint is a root of trust. It is convenient to be able to embed roots of trust into other identifiers. Over the past few years I have played with the following embedding schemes: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?phill@hallambaker.com phill@hallambaker.com.MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.onion phill@hallambaker.com.MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ The last is my preferred approach. It would be pretty easy to configure a DNS client to consider any TLD of 19 characters or more to be a fingerprint of a root of trust that governs the interpretation of the rest. The client begins by resolving MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ using whatever infrastructure exists for that task (lets call it the Mesh because we have already used nets and webs and mesh was the only one left I could think of). So the root of trust signs some record that says something like: {"DNSSEC" : "MLFXX-KIDDN-BSWG2-3FMQQ-GE5LU-EBXG6", "TLS" : "MKRUG-S4ZAN-FZSAY-LMONX-SAZTB" } These are two trust roots that can be used to interpret the address "phill@hallambaker.com". The first is the ICANN DNSSEC root, the second is a local intermediate PKIX cert for the TLS. [It isn't necessary to identify a new trust root for OpenPGP of course because that key would simply be signed in OpenPGP] Yes, there are a lot of options. But creating a lot of options does not mean that we have to have a lot of complexity. Right now, the UDF draft is an 8 pager, most of which is boilerplate: https://tools.ietf.org/html/draft-hallambaker-udf-03 I will drop in the description of the work hardening. It is simply a new algorithm type. The only impact this has on the OpenPGP use is that instead of the fingerprint being Fingerprint = H (OpenPGPFormat (Key)) It is instead: Fingerprint = VersionID + H ( "application/open-pgp-key" + H (OpenPGPFormat (Key))) Making that one change (i.e. adopting my draft) makes the fingerprint format the cornerstone of integration of OpenPGP, SSH and more into a single interoperable cryptographic infrastructure. On Sat, Apr 16, 2016 at 11:56 AM, Phillip Hallam-Baker wrote: > This is almost the scheme I am looking at. The main practical > difference is that I don't see the need to be quite so granular. If > people are going to use proof of work, then I would start off with a > threshold designed to take about an hour of processing on contemporary > machines, for the sake of argument, say that is 24 bits. Then I would > allow for prefixes of 24, 34, 40 bits. > > This approach can be encoded using a leading 1s approach. So each > increase in work saves 7 bits. > > The increase in work may look dramatic, but it really isn't because I > expect people would throw parallel machines at the problem. Also note > moving from RSA to ECC saves a huge chunk of keygen time. So any > compression scheme is having to deal with a vast difference in > computing demands and capabilities. > > The wonderful thing about exponents is that they tend to quickly > balance any mismatch in such things. > > > The other trick I think is very useful is to use truncated > fingerprints as keyIds. Lets say that we start with a SHA-51 > > > > > > On Tue, Apr 12, 2016 at 2:18 PM, Daniel Kahn Gillmor > wrote: >> On Tue 2016-04-12 13:01:14 -0400, Werner Koch wrote: >>> According to Peter, this means SHA-256. There may be no proof-of-work >>> to for creating a key and thus a structured fingerprint. (Sometimes you >>> have to create a lot of one-off keys.) >> >> The one proposal i've heard that keeps things somewhat simple but still >> allows the possibility of an increased cost to an adversary intent on a >> preimage attack is related to floating point implementations, and was >> suggested by PHB. I try to describe my understanding of the scheme >> below, but writing it all down makes me think that "somewhat simple" >> might be overselling it; there are quite a few complications. >> >> Here goes: >> >> * Start from a design of a fingerprint of X bits, using a truncation of >> digest of size Z (where Z > X). for example, a 200-bit fingerprint >> from sha-256. this would typically mean an adversary has to do about >> 2^200 sha-256 operations to find a match. (this is an impossibly >> high bar if we're talking about brute force, but if we assume that >> most cryptanalysis of SHA-256 allows an attacker to shave off some >> sizeable work factor, it represents the "safety margin" against >> unknown cryptanalysis of this type) >> >> * Instead, make the fingerprint X+N bits, where the first N bits >> indicate the number of leading zeros of the digest. Now if i do a >> bit of work to generate keys with, say, 10 leading zeros, an attacker >> will probably need to do about 2^10 more digests to find a match. >> >> So if we're doing a 200-bit truncation of sha-256, and we have an 8-bit >> count of leading zeros, and the digest produced is (in hex -- i'm not >> making an argument about choice of textual representation here, just >> showing in hex for discussion): >> >> 001a1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2 >> >> then it would result in a fingerprint of (again in hex for discussion): >> >> 0ba1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da5 >> >> That is: 11 (0x0b) bits of zeros, followed by a 1 bit, followed by >> a1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da5 >> >> More precisely, under this scheme, fingerprint generation looks like: >> >> scan1(x) : the position of the left-most 1 bit in bitstring x >> A[n:m] : bits n through m-1 of bitstring A >> enc(n,b) : a bitstring of length b encoding n as an unsigned int >> dgst(x) : a fixed-length bitstring digest of bitstring x (e.g. sha-256) >> X : number of explicitly-represented bits >> N : size of bitfield for counting leading zeros >> || : bitstring concatenation >> >> def fpr(z): >> h = dgst(z) >> k = scan1(z) >> return enc(k,N) || h[z+1:z+1+X] >> >> * note that first bit that is set to 1 is omitted from the >> representation (it's present by implication). This isn't just a hack >> to squeeze one more bit of entropy out of the fingerprint, it's >> arguably necessary to ensure that there is exactly one fingerprint >> that corresponds to any given digest. Otherwise, i can represent a >> fingerprint with 3 leading zero bits as: >> >> <3> 1100101... >> >> or: >> >> <2> 01100101... >> >> or: >> >> <1> 001100101... >> >> or: >> >> <0> 0001100101... >> >> The other alternative is to require that the leading bit after the >> zero-run prefix is always 1 (unless the zero-run prefix is maxed >> out?), which would mean that certain fingerprints are simply invalid >> (we'd want tools to reject them?) >> >> * note also that for some choices of dgst and N it would mean there >> could be some keys that are un-fingerprintable. For example, if we >> chose dgst = sha-256 and N = 5, then any key that has a sha-256 >> digest with a leading run of more than 31 zeros might be >> unrepresentable. >> >> With all these caveats, i confess the much-simpler construction "200-bit >> truncation of sha-256" looks pretty appealing :) >> >> --dkg >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp From nobody Sat Apr 16 13:16:31 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA74B12DF01 for ; Sat, 16 Apr 2016 13:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UnK-rq5Sfgt for ; Sat, 16 Apr 2016 13:16:28 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 D9FB212DEFF for ; Sat, 16 Apr 2016 13:16:27 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g184so179220343lfb.3 for ; Sat, 16 Apr 2016 13:16:27 -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; bh=hkqmyQ3nDhIsdpDJyTaUwD43dm8F50pzLn6gGsijHXA=; b=bwE7BbCMV/swzycSqkGzLyKRj4oYtt5rj2hYAieIftUHgHRTBErXlg0gmDadWDrmQw icCuqyg8NgigPbslJuMhTRgRJlKrry+2r2sfF192d5D7cUKhqdnH8FToutcxRbrCC20P i9nq7TEspKjkG0/kI7al5cTLqMtSql8adQ6khpB6vK+pRKWpZ7Y6EsKKr/TCDftjMJI3 YwgnjIHt9G9Hs8GJdRmqjd3tonEnA9QTX6nx+A0xezbJVCldSFjPUAKFQN3AbOTgbqvZ loQP8DibiP2GOzCFsIFf+GaYwRZNTi3g6oNxtnwIv3Qz2c12my+yiUV/ZX8ro1t57GJQ 6bbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hkqmyQ3nDhIsdpDJyTaUwD43dm8F50pzLn6gGsijHXA=; b=Lmt5d+hKyVlVN47WhwpHkLtt+sU/mHZjmPcncmytu3ZGuqUvA6/VJdEBsVNDQVCdKg kAKFQFp32CuDPz/pS3jGRK6cnHKJjI8GU8lcBcgTVtHgp3baYvji5mHUXlHsCMJu8J7J gBnX2uaz6YGEE23HgDj8PIIJlocH8rVDOoeHeyeIDbvVCF6xh3AYXmC24a5jZ5T3LxiM uOMz6T9TueXh+AmrUQKPXbVpFYQ03P3DLOM2kbKhvvKdZRcc1ZwyTOQyck6BCpB/Uocc AfMy13ZbYOERW8wSwx/rgbTDLdke3LV9Z2cksnNxf44rSjUZjkv0atIBZ1TxtOacrEN1 pwXA== X-Gm-Message-State: AOPr4FX5aqVAWiL5X4QdHDAW4ZAVCsbaiFkStxJS9GHIb7eO4JHVRhDxlb7l+5hwBPLNH/tBKqkwMWVXwuyNtw== MIME-Version: 1.0 X-Received: by 10.112.181.38 with SMTP id dt6mr11502782lbc.114.1460837785834; Sat, 16 Apr 2016 13:16:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Sat, 16 Apr 2016 13:16:25 -0700 (PDT) In-Reply-To: <87wpo3smzj.fsf@alice.fifthhorseman.net> References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com> <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org> <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org> <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org> <87oa9jo5sp.fsf@alice.fifthhorseman.net> <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org> <5E793A3D-128D-470A-8DF7-50827F39E02F@gmail.com> <20160410211449.GA12408@littlepip.fritz.box> <87wpo3smzj.fsf@alice.fifthhorseman.net> Date: Sat, 16 Apr 2016 16:16:25 -0400 X-Google-Sender-Auth: 3v_bDnBh5nac5x0JQ8oyCztNeWA Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Mining protection in fingerprint schemes X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 20:16:30 -0000 As a general rule, humans remember 7+/-2 items in short term (working) memory. So trying to compare two 25 character, base32 fingerprints is going to be error prone. This is why I use character grouping in my UDF proposal to group them into blocks of 5. But even that isn't ideal by any means. So yes, I agree with DKG that typing a fingerprint in (or cut n' paste) is often the way to go. As I see it, Base32 is the 'mandatory to implement' option. We need it because that is the only thing that is going to work in circumstances for which we currently use PGP fingerprints (and all the other stuff I want to support). But I don't have to be limited to just that when I am connecting my new watch to my personal set of connected devices. For that, a better choice would be a vocabulary of words or images. If the vocabulary has 65536 entries, I can encode the entire fingerprint in 6-8 images (depending on whether I choose to use work hardening). This is an option of course. But it is a very good option to have for two reasons. First it allows us to make crypto easier. But secondly, it gives a lot of people who want to help make crypto happen a tangible thing that they can work on that will help. I see compiling the dictionary as a campaign tool opportunity. Something that groups like the EFF, ACLU and such could kick off. Sanitizing a vocabulary of 64K English words would be a task a student could complete in a week. With that proof point and the tools, we would then create dictionaries for the next 32 most used languages through crowd sourcing. Every person who worked on the project would be invested in the success. They would be advocates for the system they invested in. The other approach I am rather taken by is a modification of the 'synchronized LED blink' scheme someone proposed here. It turns out there is quite a bit of prior art. Say you are in a data center. There is a red light on every CPU card, they all blink in synchronization. This tells you two things, First that they are all connected to the same clock with negligible skew and secondly that they are all controlled under the same root of trust. Isn't that exactly the sort of information that it would be great to have in a data center? The modification that I would like to see is that instead of just turning an LED on or off, it can be used to broadcast additional data or the root of trust data at a higher bitrate. The upshot of that is that when I hold a camera up to the LED, such as the one on my smartphone, it can capture data from the device at a rate of 10-Baud or so. (30fps camera / 2 - overhead). Its not exactly fast but I can get a machine readout of the trust root fingerprint and the machine fingerprint in half a minute (125 bits each) I don't know about you, but I for one would have loved being able to find out what a device was and what was controlling it in 30 seconds without unplugging it back when I did big data center stuff. Again, it is an option, it is not the mandatory to implement. But the point of having a standard is to choose something that works for both the narrow case and can be extended to new and interesting uses as well.