If you cann= ot see this=20 email, click here to view the web=20 version
<= /TABLE> ------=_NextPart_000_0007_01C9DCAD.0DF0FD40-- From owner-ietf-openpgp@mail.imc.org Sun May 24 14:31:32 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A263A68AC for ; Sun, 24 May 2009 14:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw8OVMxqsjcm for ; Sun, 24 May 2009 14:31:24 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0DB5E3A6855 for ; Sun, 24 May 2009 14:31:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLKomn098145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 14:20:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OLKofl098144; Sun, 24 May 2009 14:20:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp03.uk.clara.net (netscalibur-outbound-smtp03.uk.clara.net [213.253.59.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLKcpq098132 for ; Sun, 24 May 2009 14:20:49 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:55943) by relay03.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.43]:1325) with esmtp id 1M8L7U-0004Hh-C8 (Exim 4.69) (return-path ); Sun, 24 May 2009 22:20:36 +0100 Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 7C5915D65; Sun, 24 May 2009 22:20:31 +0100 (GMT/BST) Message-ID: <4A19BA20.9000901@systemics.com> Date: Sun, 24 May 2009 23:20:32 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: IETF OpenPGP Working Group Subject: Re: Weak crypto [was: Re: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <4A1937A8.405@epointsystem.org> In-Reply-To: <4A1937A8.405@epointsystem.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 24/5/09 14:03, Daniel A. Nagy wrote: > Hi, > > Ian G wrote: >> Nor, has 40 bit secret keys been embarrassed as yet. > > That is not true. Ah, caught by my lack of precise terms. The earlier sentence gave the clue that I meant by embarrassment: broken and money lost because of it. > Stealing luxury cars with 40-bit ciphers in their RFID keys by > brute-forcing the (cryptographic) key is routine criminal practice. > > See also http://en.wikipedia.org/wiki/Motor_vehicle_theft OK, another great data point. But other than this: # New keyless ignition/lock cars often share the same 40-bit encryption method between their "keys" and their computers. Using a RFID microreader and a laptop, university students have managed to remotely unlock, start, and drive away in top-of-the-line luxury cars, not without returning the cars to their rightful owners of course and with their consent to "steal" it in the first place.[citation needed] I see no evidence of "routine criminal practice" ... and unlike some, I explicitly exclude "university students with or without laptop" from the general class of criminals :) Don't get me wrong: it is clear that we can crunch RSA in its smallest number (which is?) and 40 bit encryption. And one day, criminals will. What is not clear is whether they must be excluded from all possible endeavours of commerce. It's that whole pareto thing again. We don't exclude software with bugs from commerce, nor paper-which-gets-lost, nor people-who-lie, nor all the other unreliable elements of life. Why are we so obsessed with impossibility in crypto? iang From owner-ietf-openpgp@mail.imc.org Sun May 24 14:38:28 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E940728C1B4 for ; Sun, 24 May 2009 14:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etLNhBQKnx-R for ; Sun, 24 May 2009 14:38:23 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F2D1328C1A3 for ; Sun, 24 May 2009 14:38:22 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLQLWJ098361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 14:26:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OLQLkn098360; Sun, 24 May 2009 14:26:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp05.uk.clara.net (netscalibur-outbound-smtp05.uk.clara.net [213.253.59.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLQA7X098348 for ; Sun, 24 May 2009 14:26:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:56455) by relay05.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.45]:1325) with esmtp id 1M8LCp-000343-Id (Exim 4.69) (return-path ); Sun, 24 May 2009 22:26:08 +0100 Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 0944F5D65; Sun, 24 May 2009 22:26:03 +0100 (GMT/BST) Message-ID: <4A19BB6C.1060307@systemics.com> Date: Sun, 24 May 2009 23:26:04 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Lionel Elie Mamane , IETF OpenPGP Working Group Subject: Re: Financial RSA crack case study: Carte Bleue & PostFinance debit cards [was: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <20090522232426.GA18238@capsaicin.mamane.lu> <4A17CBF0.7060909@systemics.com> <20090524101456.GA25020@capsaicin.mamane.lu> In-Reply-To: <20090524101456.GA25020@capsaicin.mamane.lu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the summary! I would conclude that (a) their system was a bit of a mess, and (b) it is a shame, because otherwise we would have got a clear benchmark. As the banks weren't cooperating, what we would have to do is look at the gangs and see if they could reveal the methods. Oh well, not this year. iang PS: the 320 question is that I was thinking RSA could only work down to something like 380? But then I thought about it some more, that's to do with the hash size and pacjet formats. Likely these guys didn't follow that. On 24/5/09 12:14, Lionel Elie Mamane wrote: > On Sat, May 23, 2009 at 12:12:00PM +0200, Ian G wrote: >> On 23/5/09 01:24, Lionel Elie Mamane wrote: >>> On Wed, May 06, 2009 at 12:27:13AM +0200, Ian G wrote: > >>>> The predictions of the end of the world are premature. Note that nobody >>>> has stolen money through an MD5 as yet, and nobody has stolen money >>>> because of an RSA-512, either. > >>> Maybe, but people have stolen money because of "too small RSA" >>> keys. It was RSA-320, not RSA-512. According to my sources, yp to and >>> including in the year 2007 (I don't know when it was stopped or >>> whether it was). Because the debit card of the swiss PostFinance was >>> using RSA-320 for authentication. As was the whole debit / credit card >>> system in France until the early 21st century; it seems there were >>> cases of theft up to 2001 in France. > >> Well, this is an important benchmark, if it indeed happened. > >> The questions would be: was the RSA cracked, or was it something >> else that failed? > > Executive summary: The RSA was cracked, but that is not the only non > social-engineering-or-physical attack on the system. AFAIK the RSA > crack came after the other attacks were already used in the wild. > > All the information here comes from the websites I linked to, or from > my memory of the media stories in France in 1999/2000 or talk at the > CCC, translated when needed. > > AFAIK, the issued before 1999 French "Carte Bleue" and issued up to > 2007 (and possibly later) Swiss PostFinance are exactly the same > cards. I suppose the RSA key is not the same between the two systems, > but it is the same modulus length (320 bits). The system around it > (blacklisting bad cards, when to do an on-line check before accepting > payment, ...) may vary, I don't know. > > The system has/had other security problems, but when the "factorise > the RSA public key modulus" attack got practical, it got done, > too. Especially since the factorisation started to float on the > Internet. The RSA key is not a key per card, it is the global issuer > key, that (if I remember well) signs the card info to certify that > this card is a valid one that shall be accepted for payment. > > In particular, the debit cards can/could be cloned without any > cryptographic attack (the information you need to successfully clone > is readable in cleartext without authenticating to the > smartcard). This attack requires brief access to the debit card of a > victim, and allows only making payments debited from the victim's > account, until he notices and the card number is put in the blacklist > of repudiated cards. AFAIK, in France it didn't require knowing the > PIN code of the original for payment in shops (below a certain amount > (no on-line check, only off-line between the card and the terminal) or > when the on-line checking server is blacklist-based instead of > whitelist-based), because the payment terminal asks the smartcard if > the entered PIN code is the right one; you just program the cloned > smartcard to always say yes. However, using the cloned card in ATMs > usually _did_ require knowing the right PIN, because ATMs did not use > the smartcard but the magnetic strip on the back. (There were some > attacks other than "watch the rightful owner type the PIN" to get the > right PIN; it was on the magnetic stripe and circulated over phone > lines DES-encrypted (one key per issuer bank), some ATMs contained a > copy of the key, so stealing an ATM of that bank would allow getting > the key, ...) > > Access to the RSA secret key allows to create "ex nihilo" (without > access to a genuinely issued card) cards accepted for payment by > payment terminals, but that are/were not necessarily linked to a bank > account. In France, you needed to rotate the cards every day (or > reprogram your card with a fresh number), because any card number > accepted for payment but not linked to an account got blacklisted in > the night. If you happen (by chance or design, e.g. by reading it off > a receipt found in a dustbin) to hit an issued number, the > corresponding bank account would be debited and the number blacklisted > only when the card holder notices. Because some banks had predictable > (from the old number) new card numbers when reissuing, the attacker > could then forge the new card (without access to it) and attack the > same holder again. > >> What's with the 320 number? > > I don't understand the question. > >> Secondly, was money stolen because of this? I noticed that CCC is >> in those links, and that indicates more of a "demo" quality. > > The CCC talk came years after the speaker had warned the authorities > (both the directors of the post and the federal government ministry > responsible for oversight of the post), and they failed to address the > problem, they were still issuing cards "secured" by RSA-320. Noticing > the problem in Switzerland itself came years after it hit mainstream > media in France and France solved the problem (first by moving to dual > RSA-320 and RSA-768 for newly issued cards in 1999 with a transition > period originally scheduled to go into 2004, during which old cards, > signed only by RSA-320, where still accepted; I think they then to the > EMV system, which was then scheduled to use 786 or 1024 bit keys. I'm > not sure at what date exactly they turned off acceptance of old > RSA-320 cards.). > > The "create an accepted-for-payment card ex-nihilo knowing the RSA > secret key" attack was demonstrated in France in mid-1998. The guy did > it because the banks claimed not to believe him and to want proof. He > was then charged (criminally) and sentenced in February 2000 to a > suspended prison sentence, symbolic 1,- EUR damages, 12000,- EUR > opposing counsel's fees and confiscation of his computer and smartcard > equipment. He went public to the press with the story in 1999. He did > ask the banks to pay him a fee for him to explain the attack to them > and explain how to fix it; the banks called that extortion in the PR > war, but he was never charged with anything having remotely to do with > extortion. He also lost his employment as consequence of the affair in > 1999. > > The CCC speaker was adamant that the attack was in the wild, had been > for more than two years (by December 2006) and the post refused to > reimburse victims fully. For example, he told the story of an elderly > man whose account was debited (for significant amounts) while he was > in surgery. If I remember well, that person only got 10% of the stolen > amount back. I don't remember him saying that explicitly, but my > context-in-the-talk understanding was that this would have been > through the "I know the RSA secret key" (RSA-factorisation) attack, > not a cloning attack. Whether his card number was taken by chance, > read off a receipt or written down by a cashier, I don't know. > > In France, a case from November 2001: > http://www.parodie.com/monetique/breveyescard_porteur_21112001.htm > > Naturally, the banks in France and post in Switzerland were mum about > details of fraud statistics (and claimed throughout the affairs that > the system was secure); so we don't have statistics of how much fraud > was committed through the RSA crack and how much through other > attacks. It is also hard to know whether a particular theft was done > by cloning or ex-nihilo creation (using the RSA crack). Obviously all > victims will say they never let their card in untrusted hands. But the > cloning could have happened in a twisted payment terminal, that the > victim mistook for a bona fide one. Especially since that terminal > still allowed her to pay and debited her account! > > > However, you have to realise that all building blocks were > out in the open on the Internet: > > - ASM code to program smartcards to emulate a debit card > > - factorisation of the RSA modulus (in France; for Switzerland in > 2007, your home computer could do the factorisation within one > hour, if I remember well), in a Usenet post indexed by DejaNews / > Google Groups. > > - obviously, the RSA algorithm itself (how to compute the secret key > from the two primes, how to compute a signature, ...) > > - the exact specification of what data has to be on the card and > signed > > - smartcard readers / programmers / blank cards were already rather > cheap at the time. > > I would find it hard to believe that such an easy and well documented > attack would not have been exploited, especially since it is so much > more powerful than previous attacks and does not give any additional > risk to the criminal. > > (To add insult to injury, some attacks were already documented in the > scientific literature by 1988/1990, that is before the system got > deployed, in 1993!) > >> Unfortunately my french& german isn't up to it, often a problem >> when results come from other countries. > > Is there any other information you would like? > From owner-ietf-openpgp@mail.imc.org Sun May 24 17:14:49 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92123A6891 for ; Sun, 24 May 2009 17:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2-Sn2eSn8Ki for ; Sun, 24 May 2009 17:14:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id ADEE83A692D for ; Sun, 24 May 2009 17:14:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4P05AsZ005904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 17:05:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4P05ASc005903; Sun, 24 May 2009 17:05:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4P04xAe005889 for ; Sun, 24 May 2009 17:05:09 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 427F131A10D; Mon, 25 May 2009 02:04:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id D5ADB598099; Mon, 25 May 2009 02:04:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z-1DjHLkkaBA; Mon, 25 May 2009 02:04:57 +0200 (CEST) Received: from [10.0.0.129] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id 9CB91598091; Mon, 25 May 2009 02:04:57 +0200 (CEST) Message-ID: <4A19E0A2.70604@epointsystem.org> Date: Mon, 25 May 2009 02:04:50 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ian G CC: IETF OpenPGP Working Group Subject: Re: Weak crypto [was: Re: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <4A1937A8.405@epointsystem.org> <4A19BA20.9000901@systemics.com> In-Reply-To: <4A19BA20.9000901@systemics.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF03D821D9477C6E3CE5003E0" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF03D821D9477C6E3CE5003E0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think there *is* a good reason for being more paranoid about broken cry= pto than all the other attacks: broken crypto often leaves no evidence (to th= e point of the victim not even noticing the attack) and hence leaves no room to r= eactive countermeasures. More below. Ian G wrote: > I see no evidence of "routine criminal practice" ... and unlike some, I= > explicitly exclude "university students with or without laptop" from th= e > general class of criminals :) No-no, the wikipedia link was not meant as evidence, just a description o= f the actual method. I have provided no evidence to the fact that brute-forcing= 40 bit RFID keys is routine criminal practice, because I was too lazy/busy to di= g it up. But I *have* read somewhere that several real cars (and very expensiv= e ones, at that) have been really stolen (in several countries, AFAIR) using this= technique by real criminals. For now, please take my word for it or googl= e it up yourself. A bit later, I might do the googling for you. In the context of OpenPGP, I believe that we really should exclude the possibility of attacks that penetrate our crypto, because the intended us= e cases of OpenPGP include quite a few where such an attack cannot be detected ev= en ex post. A good example would be insider trading on information gained from supposedly confidential correspondence. Such threats cannot be validated.= Weak crypto invites such attacks without any possibility of validating the vul= nerability. --=20 Daniel --------------enigF03D821D9477C6E3CE5003E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoZ4KcACgkQoeH/BzqmYjiVCACgkzJ9H1+wapX4coM+FlOh6WcK hf4An3U9YwMLXj1aR08B4tYJwFz4osUZ =WUjA -----END PGP SIGNATURE----- --------------enigF03D821D9477C6E3CE5003E0-- From openoffice@globo.com Mon May 25 05:34:15 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93193A68B0 for ; Mon, 25 May 2009 05:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.543 X-Spam-Level: X-Spam-Status: No, score=-56.543 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_RO=0.904, HS_INDEX_PARAM=0.001, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQENr+TZ+L9Z for ; Mon, 25 May 2009 05:34:13 -0700 (PDT) Received: from amerblind.outbound.ed10.com (host-89-42-87-59.bizartelecom.ro [89.42.87.59]) by core3.amsl.com (Postfix) with SMTP id 72AD33A6BBB for ; Mon, 25 May 2009 05:34:12 -0700 (PDT) X-Originating-IP: [68.0.89.4] X-Originating-Email: [openpgp-archive@ietf.org] X-Sender: openpgp-archive@ietf.org To: Subject: RE: DISCOUNT ID55778 70% 0FF on Pfizer ! From: openpgp-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20090525123412.72AD33A6BBB@core3.amsl.com> Date: Mon, 25 May 2009 05:34:12 -0700 (PDT) Welcome to WebMD

=20

2= 2.05.2009

Product=20 news

Register for Emails | Email=20 the Editor | Adverti= sing=20 Enquiries

Chemist+Druggist is published by CMPMedica - Healthcare division of=20 UBM
Company number 370721. Registered office: Ludgate House, 245=20 Blackfriars Road, London SE1 9UY
To change any of your C+D website= =20 account details click=20 here
If you would prefer not to receive newsletter emails from= =20 Chemist+Druggist please click here

• Wed, 27 May 2009 02:35:16 +0200

New from WebMD: Sign-up today!

You are subscribed as openpgp-archive@ietf.org.
View and manage your WebMD newsletter preferences.
Subscribe to more newsletters. Change/update your email address.

WebMD Privacy Policy
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
© 2009 WebMD, LLC. All rights reserved.

From nbraga@acad.unibh.br Wed May 27 01:29:05 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7193A6AC4 for ; Wed, 27 May 2009 01:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.919 X-Spam-Level: X-Spam-Status: No, score=-15.919 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdIBl+H11jHo for ; Wed, 27 May 2009 01:28:58 -0700 (PDT) Received: from accountancy.smu.edu.sg (unknown [202.81.89.116]) by core3.amsl.com (Postfix) with SMTP id BB3093A6F2D for ; Wed, 27 May 2009 01:28:50 -0700 (PDT) To: openpgp-archive@ietf.org Subject: Re: Your subscribe #733656 From: openpgp-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090527082853.BB3093A6F2D@core3.amsl.com> Date: Wed, 27 May 2009 01:28:50 -0700 (PDT)

Tell a friend Â· Download latest version

See this email as a webpage

Hello!


	Shipped Privately And Discreetly To Your Door!

We want to put a great big grin on your face in 2009. You'll be to rejoice all year.

Unsubscribe Â· Lost Password Â· Account Settings Â· Help Â· Terms of Service Â· Privacy

Ottho Heldringstraat 3, 61941 AZ Amsterdam, The Netherlands

From jmolina@aguascordillera.cl Thu May 28 19:55:21 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A073A6831 for ; Thu, 28 May 2009 19:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZWHQ8gI+kxw for ; Thu, 28 May 2009 19:55:20 -0700 (PDT) Received: from 189-19-21-160.dsl.telesp.net.br (189-19-21-160.dsl.telesp.net.br [189.19.21.160]) by core3.amsl.com (Postfix) with SMTP id 576D13A6B94 for ; Thu, 28 May 2009 19:55:18 -0700 (PDT) To: openpgp-archive@ietf.org Subject: RE: Newsletter #874743 From: openpgp-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090529025519.576D13A6B94@core3.amsl.com> Date: Thu, 28 May 2009 19:55:18 -0700 (PDT)

Tell a friend Â· Download latest version

See this email as a webpage

Hello!


	Shipped Privately And Discreetly To Your Door!

We want to put a great big grin on your face in 2009. You'll be to rejoice all year.

Unsubscribe Â· Lost Password Â· Account Settings Â· Help Â· Terms of Service Â· Privacy

Ottho Heldringstraat 9, 94130 AZ Amsterdam, The Netherlands

From fibha24@lists.us.dell.com Sat May 30 23:38:46 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E843A68EC; Sat, 30 May 2009 23:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_GREY=0.25, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l19f3YwmbKU0; Sat, 30 May 2009 23:38:38 -0700 (PDT) Received: from abtb111.neoplus.adsl.tpnet.pl (abtb111.neoplus.adsl.tpnet.pl [83.8.147.111]) by core3.amsl.com (Postfix) with ESMTP id E9E5F3A699F; Sat, 30 May 2009 23:38:37 -0700 (PDT) Message-ID: <000d01c9e1ba$97703650$6400a8c0@fibha24> From: "Natalie Fournier" To: Subject: Have a glance here if you feel like an less of a man. Date: Sun, 31 May 2009 08:39:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9E1BA.97703650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9E1BA.97703650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =09 =09 =09 =09 =20 =20 =09 =09 =09 About this mailing:=20 You are receiving this e-mail because you subscribed to MSN Featured Offers= Microsoft respects your privacy. If you do not wish to receive this MSN F= eatured Offers e-mail, please click the "Unsubscribe" link below. This will= not unsubscribe=20 you from e-mail communications from third-party advertisers that may appear= in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shal= l not be responsible or liable for the advertisers' content nor any of the = goods or service advertised. Prices and item availability subject to change without notice. 2009 Microsoft | Unsubscribe | More Newsletters | Privacy Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 =20 =20 =20 This message was sent from iContact to openpgp-archive@ietf.org. It= was sent from: iContact AutoResponder, 2635 Meridian Pkwy Suite 200, Durha= m, NC 27713. You can modify/update your subscription via the link below. =20 =20 =20 =20 =20 =20 =20 View this message in the iContact Community= : =20 =20 =20 View message =20 =20 =20 =20 Comment on this message =20 =20 =20 =20 Receive as RSS =20 =20 =20 =20 =09 =09 =09 =09 =09 ------=_NextPart_000_0007_01C9E1BA.97703650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers= Microsoft respects your privacy. If you do not wish to receive this MSN F= eatured Offers e-mail, please click the "Unsubscribe" link below. This will= not unsubscribe=20 you from e-mail communications from third-party advertisers that may appear= in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shal= l not be responsible or liable for the advertisers' content nor any of the = goods or service advertised. Prices and item availability subject to change without notice.=

2009 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

This message was sent from iContact to = openpgp-archive@ietf.org. It was sent from: iContact AutoResponder, 2635 Me= ridian Pkwy Suite 200, Durham, NC 27713. You can modify/update your subscri= ption via the link below.

View this message in the iContact Community= : =20

View message =20

Comment on this message =20

Receive as RSS

------=_NextPart_000_0007_01C9E1BA.97703650-- From l.betham@acetateproducts.com Sun May 31 15:35:04 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7CD28C1D5 for ; Sun, 31 May 2009 15:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.489 X-Spam-Level: X-Spam-Status: No, score=-14.489 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COxOPG7Wqe5K for ; Sun, 31 May 2009 15:34:57 -0700 (PDT) Received: from altuwairqi.com (unknown [190.26.29.78]) by core3.amsl.com (Postfix) with SMTP id 7212C28C1D0 for ; Sun, 31 May 2009 15:34:56 -0700 (PDT) To: openpgp-archive@ietf.org Subject: Re: Your subscribe #624277 From: openpgp-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090531-0, 31/05/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20090531223456.7212C28C1D0@core3.amsl.com> Date: Sun, 31 May 2009 15:34:56 -0700 (PDT)

Tell a friend Â· Download latest version

See this email as a webpage

Hello!


	Shipped Privately And Discreetly To Your Door!

We want to put a great big grin on your face in 2009. You'll be to rejoice all year.

Unsubscribe Â· Lost Password Â· Account Settings Â· Help Â· Terms of Service Â· Privacy

Ottho Heldringstraat 9, 23985 AZ Amsterdam, The Netherlands

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4P05AsZ005904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 17:05:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4P05ASc005903; Sun, 24 May 2009 17:05:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4P04xAe005889 for ; Sun, 24 May 2009 17:05:09 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 427F131A10D; Mon, 25 May 2009 02:04:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id D5ADB598099; Mon, 25 May 2009 02:04:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z-1DjHLkkaBA; Mon, 25 May 2009 02:04:57 +0200 (CEST) Received: from [10.0.0.129] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id 9CB91598091; Mon, 25 May 2009 02:04:57 +0200 (CEST) Message-ID: <4A19E0A2.70604@epointsystem.org> Date: Mon, 25 May 2009 02:04:50 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ian G CC: IETF OpenPGP Working Group Subject: Re: Weak crypto [was: Re: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <4A1937A8.405@epointsystem.org> <4A19BA20.9000901@systemics.com> In-Reply-To: <4A19BA20.9000901@systemics.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF03D821D9477C6E3CE5003E0" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF03D821D9477C6E3CE5003E0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think there *is* a good reason for being more paranoid about broken cry= pto than all the other attacks: broken crypto often leaves no evidence (to th= e point of the victim not even noticing the attack) and hence leaves no room to r= eactive countermeasures. More below. Ian G wrote: > I see no evidence of "routine criminal practice" ... and unlike some, I= > explicitly exclude "university students with or without laptop" from th= e > general class of criminals :) No-no, the wikipedia link was not meant as evidence, just a description o= f the actual method. I have provided no evidence to the fact that brute-forcing= 40 bit RFID keys is routine criminal practice, because I was too lazy/busy to di= g it up. But I *have* read somewhere that several real cars (and very expensiv= e ones, at that) have been really stolen (in several countries, AFAIR) using this= technique by real criminals. For now, please take my word for it or googl= e it up yourself. A bit later, I might do the googling for you. In the context of OpenPGP, I believe that we really should exclude the possibility of attacks that penetrate our crypto, because the intended us= e cases of OpenPGP include quite a few where such an attack cannot be detected ev= en ex post. A good example would be insider trading on information gained from supposedly confidential correspondence. Such threats cannot be validated.= Weak crypto invites such attacks without any possibility of validating the vul= nerability. --=20 Daniel --------------enigF03D821D9477C6E3CE5003E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoZ4KcACgkQoeH/BzqmYjiVCACgkzJ9H1+wapX4coM+FlOh6WcK hf4An3U9YwMLXj1aR08B4tYJwFz4osUZ =WUjA -----END PGP SIGNATURE----- --------------enigF03D821D9477C6E3CE5003E0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLQLWJ098361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 14:26:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OLQLkn098360; Sun, 24 May 2009 14:26:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp05.uk.clara.net (netscalibur-outbound-smtp05.uk.clara.net [213.253.59.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLQA7X098348 for ; Sun, 24 May 2009 14:26:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:56455) by relay05.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.45]:1325) with esmtp id 1M8LCp-000343-Id (Exim 4.69) (return-path ); Sun, 24 May 2009 22:26:08 +0100 Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 0944F5D65; Sun, 24 May 2009 22:26:03 +0100 (GMT/BST) Message-ID: <4A19BB6C.1060307@systemics.com> Date: Sun, 24 May 2009 23:26:04 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Lionel Elie Mamane , IETF OpenPGP Working Group Subject: Re: Financial RSA crack case study: Carte Bleue & PostFinance debit cards [was: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <20090522232426.GA18238@capsaicin.mamane.lu> <4A17CBF0.7060909@systemics.com> <20090524101456.GA25020@capsaicin.mamane.lu> In-Reply-To: <20090524101456.GA25020@capsaicin.mamane.lu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the summary! I would conclude that (a) their system was a bit of a mess, and (b) it is a shame, because otherwise we would have got a clear benchmark. As the banks weren't cooperating, what we would have to do is look at the gangs and see if they could reveal the methods. Oh well, not this year. iang PS: the 320 question is that I was thinking RSA could only work down to something like 380? But then I thought about it some more, that's to do with the hash size and pacjet formats. Likely these guys didn't follow that. On 24/5/09 12:14, Lionel Elie Mamane wrote: > On Sat, May 23, 2009 at 12:12:00PM +0200, Ian G wrote: >> On 23/5/09 01:24, Lionel Elie Mamane wrote: >>> On Wed, May 06, 2009 at 12:27:13AM +0200, Ian G wrote: > >>>> The predictions of the end of the world are premature. Note that nobody >>>> has stolen money through an MD5 as yet, and nobody has stolen money >>>> because of an RSA-512, either. > >>> Maybe, but people have stolen money because of "too small RSA" >>> keys. It was RSA-320, not RSA-512. According to my sources, yp to and >>> including in the year 2007 (I don't know when it was stopped or >>> whether it was). Because the debit card of the swiss PostFinance was >>> using RSA-320 for authentication. As was the whole debit / credit card >>> system in France until the early 21st century; it seems there were >>> cases of theft up to 2001 in France. > >> Well, this is an important benchmark, if it indeed happened. > >> The questions would be: was the RSA cracked, or was it something >> else that failed? > > Executive summary: The RSA was cracked, but that is not the only non > social-engineering-or-physical attack on the system. AFAIK the RSA > crack came after the other attacks were already used in the wild. > > All the information here comes from the websites I linked to, or from > my memory of the media stories in France in 1999/2000 or talk at the > CCC, translated when needed. > > AFAIK, the issued before 1999 French "Carte Bleue" and issued up to > 2007 (and possibly later) Swiss PostFinance are exactly the same > cards. I suppose the RSA key is not the same between the two systems, > but it is the same modulus length (320 bits). The system around it > (blacklisting bad cards, when to do an on-line check before accepting > payment, ...) may vary, I don't know. > > The system has/had other security problems, but when the "factorise > the RSA public key modulus" attack got practical, it got done, > too. Especially since the factorisation started to float on the > Internet. The RSA key is not a key per card, it is the global issuer > key, that (if I remember well) signs the card info to certify that > this card is a valid one that shall be accepted for payment. > > In particular, the debit cards can/could be cloned without any > cryptographic attack (the information you need to successfully clone > is readable in cleartext without authenticating to the > smartcard). This attack requires brief access to the debit card of a > victim, and allows only making payments debited from the victim's > account, until he notices and the card number is put in the blacklist > of repudiated cards. AFAIK, in France it didn't require knowing the > PIN code of the original for payment in shops (below a certain amount > (no on-line check, only off-line between the card and the terminal) or > when the on-line checking server is blacklist-based instead of > whitelist-based), because the payment terminal asks the smartcard if > the entered PIN code is the right one; you just program the cloned > smartcard to always say yes. However, using the cloned card in ATMs > usually _did_ require knowing the right PIN, because ATMs did not use > the smartcard but the magnetic strip on the back. (There were some > attacks other than "watch the rightful owner type the PIN" to get the > right PIN; it was on the magnetic stripe and circulated over phone > lines DES-encrypted (one key per issuer bank), some ATMs contained a > copy of the key, so stealing an ATM of that bank would allow getting > the key, ...) > > Access to the RSA secret key allows to create "ex nihilo" (without > access to a genuinely issued card) cards accepted for payment by > payment terminals, but that are/were not necessarily linked to a bank > account. In France, you needed to rotate the cards every day (or > reprogram your card with a fresh number), because any card number > accepted for payment but not linked to an account got blacklisted in > the night. If you happen (by chance or design, e.g. by reading it off > a receipt found in a dustbin) to hit an issued number, the > corresponding bank account would be debited and the number blacklisted > only when the card holder notices. Because some banks had predictable > (from the old number) new card numbers when reissuing, the attacker > could then forge the new card (without access to it) and attack the > same holder again. > >> What's with the 320 number? > > I don't understand the question. > >> Secondly, was money stolen because of this? I noticed that CCC is >> in those links, and that indicates more of a "demo" quality. > > The CCC talk came years after the speaker had warned the authorities > (both the directors of the post and the federal government ministry > responsible for oversight of the post), and they failed to address the > problem, they were still issuing cards "secured" by RSA-320. Noticing > the problem in Switzerland itself came years after it hit mainstream > media in France and France solved the problem (first by moving to dual > RSA-320 and RSA-768 for newly issued cards in 1999 with a transition > period originally scheduled to go into 2004, during which old cards, > signed only by RSA-320, where still accepted; I think they then to the > EMV system, which was then scheduled to use 786 or 1024 bit keys. I'm > not sure at what date exactly they turned off acceptance of old > RSA-320 cards.). > > The "create an accepted-for-payment card ex-nihilo knowing the RSA > secret key" attack was demonstrated in France in mid-1998. The guy did > it because the banks claimed not to believe him and to want proof. He > was then charged (criminally) and sentenced in February 2000 to a > suspended prison sentence, symbolic 1,- EUR damages, 12000,- EUR > opposing counsel's fees and confiscation of his computer and smartcard > equipment. He went public to the press with the story in 1999. He did > ask the banks to pay him a fee for him to explain the attack to them > and explain how to fix it; the banks called that extortion in the PR > war, but he was never charged with anything having remotely to do with > extortion. He also lost his employment as consequence of the affair in > 1999. > > The CCC speaker was adamant that the attack was in the wild, had been > for more than two years (by December 2006) and the post refused to > reimburse victims fully. For example, he told the story of an elderly > man whose account was debited (for significant amounts) while he was > in surgery. If I remember well, that person only got 10% of the stolen > amount back. I don't remember him saying that explicitly, but my > context-in-the-talk understanding was that this would have been > through the "I know the RSA secret key" (RSA-factorisation) attack, > not a cloning attack. Whether his card number was taken by chance, > read off a receipt or written down by a cashier, I don't know. > > In France, a case from November 2001: > http://www.parodie.com/monetique/breveyescard_porteur_21112001.htm > > Naturally, the banks in France and post in Switzerland were mum about > details of fraud statistics (and claimed throughout the affairs that > the system was secure); so we don't have statistics of how much fraud > was committed through the RSA crack and how much through other > attacks. It is also hard to know whether a particular theft was done > by cloning or ex-nihilo creation (using the RSA crack). Obviously all > victims will say they never let their card in untrusted hands. But the > cloning could have happened in a twisted payment terminal, that the > victim mistook for a bona fide one. Especially since that terminal > still allowed her to pay and debited her account! > > > However, you have to realise that all building blocks were > out in the open on the Internet: > > - ASM code to program smartcards to emulate a debit card > > - factorisation of the RSA modulus (in France; for Switzerland in > 2007, your home computer could do the factorisation within one > hour, if I remember well), in a Usenet post indexed by DejaNews / > Google Groups. > > - obviously, the RSA algorithm itself (how to compute the secret key > from the two primes, how to compute a signature, ...) > > - the exact specification of what data has to be on the card and > signed > > - smartcard readers / programmers / blank cards were already rather > cheap at the time. > > I would find it hard to believe that such an easy and well documented > attack would not have been exploited, especially since it is so much > more powerful than previous attacks and does not give any additional > risk to the criminal. > > (To add insult to injury, some attacks were already documented in the > scientific literature by 1988/1990, that is before the system got > deployed, in 1993!) > >> Unfortunately my french& german isn't up to it, often a problem >> when results come from other countries. > > Is there any other information you would like? > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLKomn098145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 14:20:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OLKofl098144; Sun, 24 May 2009 14:20:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp03.uk.clara.net (netscalibur-outbound-smtp03.uk.clara.net [213.253.59.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OLKcpq098132 for ; Sun, 24 May 2009 14:20:49 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:55943) by relay03.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.43]:1325) with esmtp id 1M8L7U-0004Hh-C8 (Exim 4.69) (return-path ); Sun, 24 May 2009 22:20:36 +0100 Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 7C5915D65; Sun, 24 May 2009 22:20:31 +0100 (GMT/BST) Message-ID: <4A19BA20.9000901@systemics.com> Date: Sun, 24 May 2009 23:20:32 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: IETF OpenPGP Working Group Subject: Re: Weak crypto [was: Re: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <4A1937A8.405@epointsystem.org> In-Reply-To: <4A1937A8.405@epointsystem.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 24/5/09 14:03, Daniel A. Nagy wrote: > Hi, > > Ian G wrote: >> Nor, has 40 bit secret keys been embarrassed as yet. > > That is not true. Ah, caught by my lack of precise terms. The earlier sentence gave the clue that I meant by embarrassment: broken and money lost because of it. > Stealing luxury cars with 40-bit ciphers in their RFID keys by > brute-forcing the (cryptographic) key is routine criminal practice. > > See also http://en.wikipedia.org/wiki/Motor_vehicle_theft OK, another great data point. But other than this: # New keyless ignition/lock cars often share the same 40-bit encryption method between their "keys" and their computers. Using a RFID microreader and a laptop, university students have managed to remotely unlock, start, and drive away in top-of-the-line luxury cars, not without returning the cars to their rightful owners of course and with their consent to "steal" it in the first place.[citation needed] I see no evidence of "routine criminal practice" ... and unlike some, I explicitly exclude "university students with or without laptop" from the general class of criminals :) Don't get me wrong: it is clear that we can crunch RSA in its smallest number (which is?) and 40 bit encryption. And one day, criminals will. What is not clear is whether they must be excluded from all possible endeavours of commerce. It's that whole pareto thing again. We don't exclude software with bugs from commerce, nor paper-which-gets-lost, nor people-who-lie, nor all the other unreliable elements of life. Why are we so obsessed with impossibility in crypto? iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OC48fC067375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 05:04:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OC48Yn067374; Sun, 24 May 2009 05:04:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OC3u7H067359 for ; Sun, 24 May 2009 05:04:07 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 6657911A53A; Sun, 24 May 2009 14:03:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id DE41E598099; Sun, 24 May 2009 14:03:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a+aNzFVu+tWa; Sun, 24 May 2009 14:03:54 +0200 (CEST) Received: from [10.0.0.129] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id AF200598091; Sun, 24 May 2009 14:03:54 +0200 (CEST) Message-ID: <4A1937A8.405@epointsystem.org> Date: Sun, 24 May 2009 14:03:52 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ian G CC: IETF OpenPGP Working Group Subject: Weak crypto [was: Re: how to specify "trust no signatures over hash X from this key"?] References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> In-Reply-To: <4A00BD41.7060807@systemics.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFF160891008B155E9CB1BCC3" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF160891008B155E9CB1BCC3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Ian G wrote: > Nor, has 40 bit secret keys been embarrassed as yet. That is not true. Stealing luxury cars with 40-bit ciphers in their RFID = keys by brute-forcing the (cryptographic) key is routine criminal practice. See also http://en.wikipedia.org/wiki/Motor_vehicle_theft --------------enigFF160891008B155E9CB1BCC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoZN6gACgkQoeH/BzqmYjhdigCgqhy+JByapYfRxaOJL90tlhY2 16oAoL24nhvyRlcHxFW2BzxNZUpxVVv/ =7QFa -----END PGP SIGNATURE----- --------------enigFF160891008B155E9CB1BCC3-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OAFC5p062086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 03:15:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OAFCwd062085; Sun, 24 May 2009 03:15:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from capsaicin.mamane.lu (5.xs4all.nl [82.95.233.223]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OAEwid062066 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 24 May 2009 03:15:10 -0700 (MST) (envelope-from master@capsaicin.mamane.lu) Received: from master by capsaicin.mamane.lu with local (Exim 4.69) (envelope-from ) id 1M8AjI-0007Fw-To; Sun, 24 May 2009 12:14:56 +0200 Date: Sun, 24 May 2009 12:14:56 +0200 From: Lionel Elie Mamane To: Ian G Cc: IETF OpenPGP Working Group Subject: Financial RSA crack case study: Carte Bleue & PostFinance debit cards [was: how to specify "trust no signatures over hash X from this key"?] Message-ID: <20090524101456.GA25020@capsaicin.mamane.lu> Mail-Followup-To: Lionel Elie Mamane , Ian G , IETF OpenPGP Working Group References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <20090522232426.GA18238@capsaicin.mamane.lu> <4A17CBF0.7060909@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A17CBF0.7060909@systemics.com> X-Operating-System: GNU/Linux X-Request-PGP: http://www.mamane.lu/openpgp/rsa_v4_4096.asc User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, May 23, 2009 at 12:12:00PM +0200, Ian G wrote: > On 23/5/09 01:24, Lionel Elie Mamane wrote: >> On Wed, May 06, 2009 at 12:27:13AM +0200, Ian G wrote: >>> The predictions of the end of the world are premature. Note that nobody >>> has stolen money through an MD5 as yet, and nobody has stolen money >>> because of an RSA-512, either. >> Maybe, but people have stolen money because of "too small RSA" >> keys. It was RSA-320, not RSA-512. According to my sources, yp to and >> including in the year 2007 (I don't know when it was stopped or >> whether it was). Because the debit card of the swiss PostFinance was >> using RSA-320 for authentication. As was the whole debit / credit card >> system in France until the early 21st century; it seems there were >> cases of theft up to 2001 in France. > Well, this is an important benchmark, if it indeed happened. > The questions would be: was the RSA cracked, or was it something > else that failed? Executive summary: The RSA was cracked, but that is not the only non social-engineering-or-physical attack on the system. AFAIK the RSA crack came after the other attacks were already used in the wild. All the information here comes from the websites I linked to, or from my memory of the media stories in France in 1999/2000 or talk at the CCC, translated when needed. AFAIK, the issued before 1999 French "Carte Bleue" and issued up to 2007 (and possibly later) Swiss PostFinance are exactly the same cards. I suppose the RSA key is not the same between the two systems, but it is the same modulus length (320 bits). The system around it (blacklisting bad cards, when to do an on-line check before accepting payment, ...) may vary, I don't know. The system has/had other security problems, but when the "factorise the RSA public key modulus" attack got practical, it got done, too. Especially since the factorisation started to float on the Internet. The RSA key is not a key per card, it is the global issuer key, that (if I remember well) signs the card info to certify that this card is a valid one that shall be accepted for payment. In particular, the debit cards can/could be cloned without any cryptographic attack (the information you need to successfully clone is readable in cleartext without authenticating to the smartcard). This attack requires brief access to the debit card of a victim, and allows only making payments debited from the victim's account, until he notices and the card number is put in the blacklist of repudiated cards. AFAIK, in France it didn't require knowing the PIN code of the original for payment in shops (below a certain amount (no on-line check, only off-line between the card and the terminal) or when the on-line checking server is blacklist-based instead of whitelist-based), because the payment terminal asks the smartcard if the entered PIN code is the right one; you just program the cloned smartcard to always say yes. However, using the cloned card in ATMs usually _did_ require knowing the right PIN, because ATMs did not use the smartcard but the magnetic strip on the back. (There were some attacks other than "watch the rightful owner type the PIN" to get the right PIN; it was on the magnetic stripe and circulated over phone lines DES-encrypted (one key per issuer bank), some ATMs contained a copy of the key, so stealing an ATM of that bank would allow getting the key, ...) Access to the RSA secret key allows to create "ex nihilo" (without access to a genuinely issued card) cards accepted for payment by payment terminals, but that are/were not necessarily linked to a bank account. In France, you needed to rotate the cards every day (or reprogram your card with a fresh number), because any card number accepted for payment but not linked to an account got blacklisted in the night. If you happen (by chance or design, e.g. by reading it off a receipt found in a dustbin) to hit an issued number, the corresponding bank account would be debited and the number blacklisted only when the card holder notices. Because some banks had predictable (from the old number) new card numbers when reissuing, the attacker could then forge the new card (without access to it) and attack the same holder again. > What's with the 320 number? I don't understand the question. > Secondly, was money stolen because of this? I noticed that CCC is > in those links, and that indicates more of a "demo" quality. The CCC talk came years after the speaker had warned the authorities (both the directors of the post and the federal government ministry responsible for oversight of the post), and they failed to address the problem, they were still issuing cards "secured" by RSA-320. Noticing the problem in Switzerland itself came years after it hit mainstream media in France and France solved the problem (first by moving to dual RSA-320 and RSA-768 for newly issued cards in 1999 with a transition period originally scheduled to go into 2004, during which old cards, signed only by RSA-320, where still accepted; I think they then to the EMV system, which was then scheduled to use 786 or 1024 bit keys. I'm not sure at what date exactly they turned off acceptance of old RSA-320 cards.). The "create an accepted-for-payment card ex-nihilo knowing the RSA secret key" attack was demonstrated in France in mid-1998. The guy did it because the banks claimed not to believe him and to want proof. He was then charged (criminally) and sentenced in February 2000 to a suspended prison sentence, symbolic 1,- EUR damages, 12000,- EUR opposing counsel's fees and confiscation of his computer and smartcard equipment. He went public to the press with the story in 1999. He did ask the banks to pay him a fee for him to explain the attack to them and explain how to fix it; the banks called that extortion in the PR war, but he was never charged with anything having remotely to do with extortion. He also lost his employment as consequence of the affair in 1999. The CCC speaker was adamant that the attack was in the wild, had been for more than two years (by December 2006) and the post refused to reimburse victims fully. For example, he told the story of an elderly man whose account was debited (for significant amounts) while he was in surgery. If I remember well, that person only got 10% of the stolen amount back. I don't remember him saying that explicitly, but my context-in-the-talk understanding was that this would have been through the "I know the RSA secret key" (RSA-factorisation) attack, not a cloning attack. Whether his card number was taken by chance, read off a receipt or written down by a cashier, I don't know. In France, a case from November 2001: http://www.parodie.com/monetique/breveyescard_porteur_21112001.htm Naturally, the banks in France and post in Switzerland were mum about details of fraud statistics (and claimed throughout the affairs that the system was secure); so we don't have statistics of how much fraud was committed through the RSA crack and how much through other attacks. It is also hard to know whether a particular theft was done by cloning or ex-nihilo creation (using the RSA crack). Obviously all victims will say they never let their card in untrusted hands. But the cloning could have happened in a twisted payment terminal, that the victim mistook for a bona fide one. Especially since that terminal still allowed her to pay and debited her account! However, you have to realise that all building blocks were out in the open on the Internet: - ASM code to program smartcards to emulate a debit card - factorisation of the RSA modulus (in France; for Switzerland in 2007, your home computer could do the factorisation within one hour, if I remember well), in a Usenet post indexed by DejaNews / Google Groups. - obviously, the RSA algorithm itself (how to compute the secret key from the two primes, how to compute a signature, ...) - the exact specification of what data has to be on the card and signed - smartcard readers / programmers / blank cards were already rather cheap at the time. I would find it hard to believe that such an easy and well documented attack would not have been exploited, especially since it is so much more powerful than previous attacks and does not give any additional risk to the criminal. (To add insult to injury, some attacks were already documented in the scientific literature by 1988/1990, that is before the system got deployed, in 1993!) > Unfortunately my french & german isn't up to it, often a problem > when results come from other countries. Is there any other information you would like? -- Lionel Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NACFXc080304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 03:12:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NACF6g080303; Sat, 23 May 2009 03:12:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp05.uk.clara.net (netscalibur-outbound-smtp05.uk.clara.net [213.253.59.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NAC4Fb080289 for ; Sat, 23 May 2009 03:12:14 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:916) by relay05.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.45]:1325) with esmtp id 1M7oCv-0008OY-Iw (Exim 4.69) (return-path ); Sat, 23 May 2009 11:12:02 +0100 Received: from [IPv6:::1] (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 0BCF55D65; Sat, 23 May 2009 11:11:57 +0100 (GMT/BST) Message-ID: <4A17CBF0.7060909@systemics.com> Date: Sat, 23 May 2009 12:12:00 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Lionel Elie Mamane , IETF OpenPGP Working Group Subject: Re: how to specify "trust no signatures over hash X from this key"? References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> <20090522232426.GA18238@capsaicin.mamane.lu> In-Reply-To: <20090522232426.GA18238@capsaicin.mamane.lu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 23/5/09 01:24, Lionel Elie Mamane wrote: > On Wed, May 06, 2009 at 12:27:13AM +0200, Ian G wrote: > >> The predictions of the end of the world are premature. Note that nobody >> has stolen money through an MD5 as yet, and nobody has stolen money >> because of an RSA-512, either. > > Maybe, but people have stolen money because of "too small RSA" > keys. It was RSA-320, not RSA-512. According to my sources, yp to and > including in the year 2007 (I don't know when it was stopped or > whether it was). Because the debit card of the swiss PostFinance was > using RSA-320 for authentication. As was the whole debit / credit card > system in France until the early 21st century; it seems there were > cases of theft up to 2001 in France. > > France: > http://www.parodie.com/monetique/breveyescard_porteur_21112001.htm > http://www.parodie.com/monetique/ > > Switzerland: > http://events.ccc.de/congress/2006/Fahrplan/events/1775.en.html > http://www.postcard-sicherheit.ch/ > http://chaostreff-zh.tuners.ch/Pestcard > Well, this is an important benchmark, if it indeed happened. The questions would be: was the RSA cracked, or was it something else that failed? Or a combination of things? What's with the 320 number? Secondly, was money stolen because of this? I noticed that CCC is in those links, and that indicates more of a "demo" quality. Unfortunately my french & german isn't up to it, often a problem when results come from other countries. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4MNOgQG045206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 16:24:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4MNOgji045205; Fri, 22 May 2009 16:24:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from capsaicin.mamane.lu (5.xs4all.nl [82.95.233.223]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4MNOT7u045186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 22 May 2009 16:24:40 -0700 (MST) (envelope-from master@capsaicin.mamane.lu) Received: from master by capsaicin.mamane.lu with local (Exim 4.69) (envelope-from ) id 1M7e6E-0004zO-UT; Sat, 23 May 2009 01:24:27 +0200 Date: Sat, 23 May 2009 01:24:26 +0200 From: Lionel Elie Mamane To: Ian G Cc: IETF OpenPGP Working Group Subject: Re: how to specify "trust no signatures over hash X from this key"? Message-ID: <20090522232426.GA18238@capsaicin.mamane.lu> Mail-Followup-To: Lionel Elie Mamane , Ian G , IETF OpenPGP Working Group References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> <4A00BD41.7060807@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A00BD41.7060807@systemics.com> X-Operating-System: GNU/Linux X-Request-PGP: http://www.mamane.lu/openpgp/rsa_v4_4096.asc User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 06, 2009 at 12:27:13AM +0200, Ian G wrote: > The predictions of the end of the world are premature. Note that nobody > has stolen money through an MD5 as yet, and nobody has stolen money > because of an RSA-512, either. Maybe, but people have stolen money because of "too small RSA" keys. It was RSA-320, not RSA-512. According to my sources, yp to and including in the year 2007 (I don't know when it was stopped or whether it was). Because the debit card of the swiss PostFinance was using RSA-320 for authentication. As was the whole debit / credit card system in France until the early 21st century; it seems there were cases of theft up to 2001 in France. France: http://www.parodie.com/monetique/breveyescard_porteur_21112001.htm http://www.parodie.com/monetique/ Switzerland: http://events.ccc.de/congress/2006/Fahrplan/events/1775.en.html http://www.postcard-sicherheit.ch/ http://chaostreff-zh.tuners.ch/Pestcard -- Lionel Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4C5fVRk015727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 22:41:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4C5fV4b015726; Mon, 11 May 2009 22:41:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4C5fJcW015714 for ; Mon, 11 May 2009 22:41:30 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 9B08D11AD04 for ; Tue, 12 May 2009 07:41:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id C6F19598099 for ; Tue, 12 May 2009 07:41:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xn-1VN4rsHtD for ; Tue, 12 May 2009 07:41:17 +0200 (CEST) Received: from [10.0.0.129] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id 9143B598091 for ; Tue, 12 May 2009 07:41:17 +0200 (CEST) Message-ID: <4A090BF5.6090805@epointsystem.org> Date: Tue, 12 May 2009 07:41:09 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: collision-resistance and self-signatures [was: Re: Non-SHA-1 fingerprints] References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <4A08916E.4000902@fifthhorseman.net> In-Reply-To: <4A08916E.4000902@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBE9288F01ECA740305A0E4C1" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBE9288F01ECA740305A0E4C1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think, you are right. My bad. Daniel Kahn Gillmor wrote: > (dredging this up from a week ago because i was re-thinking it today) >=20 > On 05/04/2009 06:04 PM, Daniel A. Nagy wrote: >> For fingerprints, MDC and self-signatures, collision-resistance does n= ot matter, >> only the one-way property. So I think it is totally safe to postpone d= iscussion >> until SHA3 is selected. >=20 > I think this point holds for fingerprints and MDCs. I'm not convinced > that it holds for self-signatures, though. >=20 > Let's assume Alice has an SHA-1 collision-generator that she can coax > into generating two messages, A and B with the same digest, and that sh= e > is meeting Bob for a keysigning at the pub on Friday. >=20 > She crafts message A, which looks like a regular public key/uid > signature, including friday evening's timestamp and her User ID (this i= s > exactly the information to be hashed in a non-self-signature -- maybe i= t > hides the collision-generating bits in one of the public key MPIs?). > Message B is the data within a self-signature over Bob's key, asserting= > something Bob didn't want to assert (e.g. binding a user ID of a known > villain, or binding a false encryption subkey which Alice controls). > The collision-generating bits in B might be hidden here in a notation > subpacket or something similarly opaque. >=20 > At the pub, Alice gets Bob to sign her key (message A) at just the righ= t > time, retrieves his signature, and transfers it to the new bogus > self-sig (message B). >=20 > I think this means we need to consider self-signatures made over a give= n > algorithm as potentially spoofable if the digest's collision-resistance= > is weakened. It is *not* just the one-wayness that matters for self-si= gs. >=20 > Is this analysis reasonable? What have i missed? >=20 > --dkg >=20 > PS i know that no one has demonstrated anything remotely close to the > hypothesized oracle i've given Alice above. The point is just that > collision-resistance affects self-sigs in ways that it does not affect > the MDC or the fingerprint. >=20 --------------enigBE9288F01ECA740305A0E4C1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoJC/wACgkQoeH/BzqmYjhJZACeKAuRrkPYj3iHa5gAtG+4ZEKg u9AAoL4L8gQPaZzN1HPT39ObaIO70F85 =Eskt -----END PGP SIGNATURE----- --------------enigBE9288F01ECA740305A0E4C1-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4BKvZgr091809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 13:57:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4BKvZOr091808; Mon, 11 May 2009 13:57:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n4BKvO0W091797 for ; Mon, 11 May 2009 13:57:35 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 93868 invoked from network); 11 May 2009 20:57:22 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 11 May 2009 20:57:22 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <4A08916E.4000902@fifthhorseman.net> Date: Mon, 11 May 2009 16:58:22 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: collision-resistance and self-signatures [was: Re: Non-SHA-1 fingerprints] References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> In-Reply-To: <49FF6677.7070907@epointsystem.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3E288F6834146C1C811D07D6" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3E288F6834146C1C811D07D6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (dredging this up from a week ago because i was re-thinking it today) On 05/04/2009 06:04 PM, Daniel A. Nagy wrote: > For fingerprints, MDC and self-signatures, collision-resistance does no= t matter, > only the one-way property. So I think it is totally safe to postpone di= scussion > until SHA3 is selected. I think this point holds for fingerprints and MDCs. I'm not convinced that it holds for self-signatures, though. Let's assume Alice has an SHA-1 collision-generator that she can coax into generating two messages, A and B with the same digest, and that she is meeting Bob for a keysigning at the pub on Friday. She crafts message A, which looks like a regular public key/uid signature, including friday evening's timestamp and her User ID (this is exactly the information to be hashed in a non-self-signature -- maybe it hides the collision-generating bits in one of the public key MPIs?). Message B is the data within a self-signature over Bob's key, asserting something Bob didn't want to assert (e.g. binding a user ID of a known villain, or binding a false encryption subkey which Alice controls). The collision-generating bits in B might be hidden here in a notation subpacket or something similarly opaque. At the pub, Alice gets Bob to sign her key (message A) at just the right time, retrieves his signature, and transfers it to the new bogus self-sig (message B). I think this means we need to consider self-signatures made over a given algorithm as potentially spoofable if the digest's collision-resistance is weakened. It is *not* just the one-wayness that matters for self-sigs= =2E Is this analysis reasonable? What have i missed? --dkg PS i know that no one has demonstrated anything remotely close to the hypothesized oracle i've given Alice above. The point is just that collision-resistance affects self-sigs in ways that it does not affect the MDC or the fingerprint. --------------enig3E288F6834146C1C811D07D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSgiRf8zS7ZTSFznpAQrFLw/9EAnXGMWkzvNq39vQbSnfeKRgN6wdp58W BleRzhBLyb112LKpt7RZclRcbFtb26+Fr6mpzite7/zhn+ejWKIxdWSD+L79RLF6 V9YRpvtMGl3ja+MB1FPQpUBc5Rchvr+VHH1UlkhXh9BAKX+az5TWbEb6itVKk2Qg 1ilU7MK9bUZv3zsjrj8Bu6SBYza6q/Fk6FDpXVGlcKsTZ6HAiukmO/iE/EFJnZZP qVeEwZZ/g8UYCmFFbgJLaRv67VpvNulP3GPJTg9c28SwVO1l0lTkQjQkFobjU8+o YI/+FodxbSILIXuYbgq43JU0IQ9S5+GUSDO4Z40zf+rz4B+tTHGiavW7+oTIyHg9 S8S3ZGPLMofuy2ciJTaTwveTFhfMJ6YCySXTifIOutoz1HzjbDnGUL0VzTRynAic v7WnihVSVpLDYRjF3tLNR5D7Ow7DcU8MZTmbFyBJCvCDR7Bj989+Im2iXPGMiIZ2 EcCNB5evIQ+qG4/ZaCOap6202ZG5jcwy4AfWEzjvPdMja2+volYZG4Nyw6axKnJ0 PxwqmYLFgkY/Ab+l1W2AK23qA333Iq+/SCPKVH30XbQ6NWv+qmlBuvWKiO+fFGjY eM5+W2KZgtE4Kux8imx2hTAzg5zOrs8UiNUb6ZXpody/wYxVdkg+0UuxnnwEUXPI g41NE3JD75s= =JqA8 -----END PGP SIGNATURE----- --------------enig3E288F6834146C1C811D07D6-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n48Kllvm059306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 13:47:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n48Klldp059305; Fri, 8 May 2009 13:47:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n48KlZsJ059290 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 8 May 2009 13:47:47 -0700 (MST) (envelope-from fw@deneb.enyo.de) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1M2Wyf-0003X8-Uj; Fri, 08 May 2009 22:47:30 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1M2Wyf-0000r1-ID; Fri, 08 May 2009 22:47:29 +0200 From: Florian Weimer To: Jon Callas Cc: OpenPGP Working Group Subject: Re: I don't think that collides the way you think it does References: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> Date: Fri, 08 May 2009 22:47:29 +0200 In-Reply-To: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> (Jon Callas's message of "Tue, 5 May 2009 10:58:14 -0700") Message-ID: <87skjfcof2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Jon Callas: > The new results for 2^52 work, assuming it's actually doable, are > still for migrating a bitstring into two dependent bitstrings that > collide. This has significance for people who run CAs with sequential > serial numbers, or who want to tweak PDFs to project the future, or > create binary distributions that have and do not have malware. It's > serious *for* *those* *and* *similar* *cases*. Unfortunately, signing someone else's key and user ID is a similar case. You don't know what you're being asked to sign, and you haven't created the document yourself. And a photo ID gives you many bits to play with. In the abstract, you do not actually need collision resistance (and totally keyless hashes) for OpenPGP-like protocols, but current practice is certainly different. IMHO, an eventual OpenPGP successor should prepend salts/IVs in front of signatures. Of course, this might be used as a relatively high-bandwidth covert channel, but it means that the hash function will likely last somewhat longer. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47Hk0MT058473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 10:46:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47Hk0S1058472; Thu, 7 May 2009 10:46:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n47Hjn8Z058453 for ; Thu, 7 May 2009 10:45:59 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 54584 invoked from network); 7 May 2009 17:45:48 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay00.pair.com with SMTP; 7 May 2009 17:45:48 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <4A031E88.5020304@fifthhorseman.net> Date: Thu, 07 May 2009 13:46:48 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: keyids vs. fingerprints [was: Re: Fix revocation keys instead of fingerprints?] References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> <49FFD926.20802@epointsystem.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4F4AB24288A4BF6E2FDF8F74" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F4AB24288A4BF6E2FDF8F74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/07/2009 11:45 AM, David Shaw wrote: > On May 5, 2009, at 2:13 AM, Daniel A. Nagy wrote: >> David Shaw wrote: >>> Fingerprints: >>> * Must be human-readable >>> * Needs to be small to be useful >>> * Can collide to some small amount (4880 even documents that they >>> collide in section 12.2) >> >> That's not the fingerprint. That's the key ID. >=20 > A nit, but that really is the fingerprint. The important items here are 1 and 2, which both apply to a fingerprint. Humans need to be able to cognitively compare fingerprints, so they must be both human-readable and small enough to wade through. As for collisions, 32-bit key ids don't collide "to some small amount". They have *massive* collisions because of the small output space. It takes a few hours of compute time on a single modern desktop machine to generate 32-bit keyID collisions against every single key in the public WoT. 64-bit keyids are better, but still nowhere near the collision resistance we should be expecting from tools we expect humans to use to validate content. keyIDs are useful as pointers, but are not at all useful for verification purposes. --dkg --------------enig4F4AB24288A4BF6E2FDF8F74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSgMejczS7ZTSFznpAQr9zw//TuBcCa2w9WVgU6mUTM8jke6BlILQqo/Q i/rct3ZKWkPhAH3ymMU5KE+MU8aNx7s09Q890anK+Kso/wwklh+UhI+j5//Ys9Uz Q5Sf7ZALcIXn/TTxo5/v8RENuYopW7d4Trm79ctDx6HgAxc8lAU8GGrm/69FJYSA P+xstUybrbKIhlf9tlm23OSrt6+QVfVw0HyeOCZo4GOF151ivXFkOOFLlOwJuqN5 qSTIk8FrEJxZrgzV3xfFDeSYp5XvjUhRmOwn4S/hlAwQr1KOe3diUK53n5nN/xLz qX2G7JTWd2w/3xI+l8gy1fXLGTAZKDw4eO+WQOmZHsSzwVsWLmquW1rekfW1mzQC m5D5gub3BcSFGA89y70aOgD5T8S6S0ZYpDS7yodJSFfAOQ0X06OEezC6oZKr4AKu zbLGs3Ja5ZUH0J+4JMBd1BA7Uc1krLnUssJxTYi2kTdY3I8LDc4qvuPNFqaQ1yyo BFgaoX8yCJVjqQ6lYUmErLEglsrPecPHsSTjuHPJPPTJDORdgLDc0or2AjbDgZSe g+1OKWeXIaRrtm84pWXgGGW7xNaMWTR9DHCbgHgkvq0wFCUm5tCXD6hgfO54Bjno JZyIEyYf7h7BYMmQd5Wr5DkvJ3V7fPHwPUNMCzWzwdHqh2rVPf8u1LoxiHU2q+sI C59VrAVNTsU= =0mp0 -----END PGP SIGNATURE----- --------------enig4F4AB24288A4BF6E2FDF8F74-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47H6caX056226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 10:06:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47H6cVJ056225; Thu, 7 May 2009 10:06:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47H6RDG056207 for ; Thu, 7 May 2009 10:06:37 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 2EAB911A193; Thu, 7 May 2009 19:06:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id C9B10598099; Thu, 7 May 2009 19:06:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id azfR40wWvHfj; Thu, 7 May 2009 19:06:25 +0200 (CEST) Received: from [157.181.227.235] (dhcp235.cs.elte.hu [157.181.227.235]) by mail.agileight.com (Postfix) with ESMTP id 89FBC598091; Thu, 7 May 2009 19:06:25 +0200 (CEST) Message-ID: <4A03150C.7050908@epointsystem.org> Date: Thu, 07 May 2009 19:06:20 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: David Shaw CC: IETF OpenPGP Working Group Subject: Re: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fingerprints) References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> <49FFD926.20802@epointsystem.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig44DC6E51A3726AD501084468" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44DC6E51A3726AD501084468 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, David Shaw wrote: > On May 5, 2009, at 2:13 AM, Daniel A. Nagy wrote: >=20 >> Hi, >> >> David Shaw wrote: >>> It's a larger problem than just fingerprints. We also use a fingerpr= int >>> as a specifier inside the revocation key subpacket, to designate whic= h >>> key can be used to issue revocations on our behalf. The thing is, >>> though, a fingerprint isn't really a very good revocation key specifi= er: >>> >>> Fingerprints: >>> * Must be human-readable >>> * Needs to be small to be useful >>> * Can collide to some small amount (4880 even documents that they >>> collide in section 12.2) >> >> That's not the fingerprint. That's the key ID. >=20 > A nit, but that really is the fingerprint. >=20 > 12.2: >=20 > Note that there is a much smaller, but still non-zero, probability > that two different keys have the same fingerprint. While the probability is non-zero, but it is roughly equal to accidentall= y guessing the discrete logarithm of a DSA key or a prime factor of the RSA= key. > It's not exactly *likely*, but it's not quite zero. I heard a > urban-legendish story once about someone who (completely accidentally) > generated a key that just happened to have a fingerprint collision with= > someone else's key. Unfortunately, thinking it was a bug, they deleted= > the key... make of that what you will :) There WAS a bug and he did the right thing. --=20 Daniel --------------enig44DC6E51A3726AD501084468 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoDFREACgkQoeH/BzqmYjjeUgCaA14f3l3FFh1akECwPoxEeLUa W6gAmgOXrbr8LyFINqUS55xAQvei3b8u =u3K1 -----END PGP SIGNATURE----- --------------enig44DC6E51A3726AD501084468-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47FjOBS050354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 08:45:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47FjOxB050353; Thu, 7 May 2009 08:45:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47FjBbw050335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2009 08:45:23 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (system178.22.202.65 [65.202.22.178] (may be forged)) (authenticated bits=0) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n47Fj8O9003930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 May 2009 11:45:09 -0400 Cc: IETF OpenPGP Working Group Message-Id: From: David Shaw To: "Daniel A. Nagy" In-Reply-To: <49FFD926.20802@epointsystem.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Subject: Re: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fingerprints) Date: Thu, 7 May 2009 11:45:08 -0400 References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> <49FFD926.20802@epointsystem.org> X-Mailer: Apple Mail (2.930.4) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 5, 2009, at 2:13 AM, Daniel A. Nagy wrote: > Hi, > > David Shaw wrote: >> It's a larger problem than just fingerprints. We also use a >> fingerprint >> as a specifier inside the revocation key subpacket, to designate >> which >> key can be used to issue revocations on our behalf. The thing is, >> though, a fingerprint isn't really a very good revocation key >> specifier: >> >> Fingerprints: >> * Must be human-readable >> * Needs to be small to be useful >> * Can collide to some small amount (4880 even documents that they >> collide in section 12.2) > > That's not the fingerprint. That's the key ID. A nit, but that really is the fingerprint. 12.2: Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint. It's not exactly *likely*, but it's not quite zero. I heard a urban- legendish story once about someone who (completely accidentally) generated a key that just happened to have a fingerprint collision with someone else's key. Unfortunately, thinking it was a bug, they deleted the key... make of that what you will :) David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n465nmig005151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 22:49:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n465nmM4005150; Tue, 5 May 2009 22:49:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n465nb8f005142 for ; Tue, 5 May 2009 22:49:48 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 83334 invoked from network); 6 May 2009 05:49:36 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay00.pair.com with SMTP; 6 May 2009 05:49:36 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <4A012528.3080501@fifthhorseman.net> Date: Wed, 06 May 2009 01:50:32 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: building up the post-SHA1 Web of Trust X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9; url=http://fifthhorseman.net/dkg.gpg Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8E6632BDC9EEDBA49FB9BB73" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E6632BDC9EEDBA49FB9BB73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi people-- I just made a fairly gpg-specific blog post suggesting concrete, non-disruptive actions that people can take now to start building out the post-SHA1 Web of Trust: http://www.debian-administration.org/users/dkg/weblog/48 I realize this is a somewhat controversial topic, and i'm not trying to start a flamewar. I do welcome questions, comments, and criticism, though, and i'd be very happy to be able to link to similar HOWTOs for other OpenPGP implementations if anyone else has written them. The actual abandonment of SHA1 is still a ways off, and nothing in my post suggests that we *should* abandon it now. My goal is to see the Web of Trust be sufficiently robust well before SHA-1 is finally deprecated, and this seems possible with current tools and protocols, if we go about it reasonably and start early enough. I really appreciate all the knowledge people have shared on this list about the subject recently. I've learned a lot in the last few days, and hope i haven't screwed anything up too badly. Regards, --dkg --------------enig8E6632BDC9EEDBA49FB9BB73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSgElLczS7ZTSFznpAQowdA//YOcupFAs/Hb9ZD87PGy77kZ6tjO2ZTJZ 2qVz+9qBF8jMynJlXp6F5rvmdTum5bS1PGSDDCcepih9h6nV21UUY1D1mAD3TSlI ffehldROOSQqO6/4fUz3Hh3UTGGICE6MuJsgsVz9AEJdoXZIgpaPEDy3oY+o/T0C n7VKaKbnrvvDAK9x9xI3QZj1wQKThMangetmHiSuDyCPmAD0nZEK27uiXwXSikkb NrszgUW/aH3zyO4moJswJuryIEVvh0tXwBiyspnPiYn+JVocF+Fxenc8p+fzBdtN Lo0pvZZf8+glz9UkftXYjfKPvP1g5a0IVqPs9sUOrK0M5z/ccWsPTsnYA2NBB5MB uS7hZBEHhv5AX1QLimGb4iBAZ/lGSR+zzGiT8umCZpoKNz/mNWKqPPlj51J40iEg VmkUD9FLQ/8KfOsYm4GiRXTM6MD3BqnStJDyMSJHBWY7lABU2hbJrj7v5SSbUYP6 LZmpc0wi508urJLcMquAZA4GPsK9IizbRxliCDEOLWy1K3GbZiWSJeKJ9aQHLinY 3JTACz7/VGaO3+B238n0ViFw1/ZvBcJFgOLtdWY1f18ngvT2JXjdDsqRIb1B5dG0 XTkjRYFouVwj9LC34Z69/y4165KdzUw+ZVx2Kg/Wlr4EhHO3DgnMMa9yF8tDuHYq YHxOvZdONuo= =eChL -----END PGP SIGNATURE----- --------------enig8E6632BDC9EEDBA49FB9BB73-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45N0vrt083597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 16:00:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45N0vai083596; Tue, 5 May 2009 16:00:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45N0jfN083581 for ; Tue, 5 May 2009 16:00:56 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 8A08511A1A8; Wed, 6 May 2009 01:00:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 173EC598099; Wed, 6 May 2009 01:00:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zeOzR+syRu8S; Wed, 6 May 2009 01:00:43 +0200 (CEST) Received: from [10.0.0.232] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id D25BF598091; Wed, 6 May 2009 01:00:43 +0200 (CEST) Message-ID: <4A00C515.6000100@epointsystem.org> Date: Wed, 06 May 2009 01:00:37 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Daniel Franke CC: Jon Callas , OpenPGP Working Group Subject: Re: I don't think that collides the way you think it does References: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> <87eiv3cq9a.fsf@feanor.dfranke.us> In-Reply-To: <87eiv3cq9a.fsf@feanor.dfranke.us> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig40F5A262D60EEB9E17B2A2D8" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig40F5A262D60EEB9E17B2A2D8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Franke wrote: > Jon Callas writes: >=20 >> Adi Shamir has pointed out for years now that no one has found *any* = >> first or second preimage collision for SHA1. I'll shill for him here. >> >> The new results for 2^52 work, assuming it's actually doable, are =20 >> still for migrating a bitstring into two dependent bitstrings that =20 >> collide. This has significance for people who run CAs with sequential = =20 >> serial numbers, or who want to tweak PDFs to project the future, or =20 >> create binary distributions that have and do not have malware. It's =20 >> serious *for* *those* *and* *similar* *cases*. >=20 > I think you mean "no one has found any first or second preimage > *attacks* for SHA-1". To the best of my knowledge, nobody has found an= y > SHA-1 collisions at all, either chosen or otherwise. The 2^52 result i= s > still theoretical, because while 2^52 hash operations is tractable for = a > WFO, it's still a formidable amount of work, and Cameron McDonald is no= t > a WFO. Just to give you some perspective what WFO means at this day and age: my cryptography lab at the University has just built and tested a DES cracke= r that cost us less than =E2=82=AC20000 EUR. It iterates through the 56-bit key = space in about one week. We are considering using it for finding a SHA1 collision using these new results. But, as noted above, this would be a collision where both pre-im= ages are carefully chosen by the attacker. --=20 Daniel --------------enig40F5A262D60EEB9E17B2A2D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoAxRoACgkQoeH/BzqmYjiJ3gCeL2/PxzNTS9+M79gZAQLAe3a7 NgwAoIw3e4dcVFtkC04JIqSwg405QlUp =tkBu -----END PGP SIGNATURE----- --------------enig40F5A262D60EEB9E17B2A2D8-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45MRXEw081556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:27:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45MRXv1081555; Tue, 5 May 2009 15:27:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp03.uk.clara.net (netscalibur-outbound-smtp03.uk.clara.net [213.253.59.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45MRMJF081540 for ; Tue, 5 May 2009 15:27:32 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:29068) by relay03.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.43]:1325) with esmtp id 1M1T6e-0006zP-B0 (Exim 4.69) (return-path ); Tue, 05 May 2009 23:27:20 +0100 Received: from ip80-101-235-1.hotspotsvankpn.com (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 2703C5D65; Tue, 5 May 2009 23:27:12 +0100 (GMT/BST) Message-ID: <4A00BD41.7060807@systemics.com> Date: Wed, 06 May 2009 00:27:13 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: how to specify "trust no signatures over hash X from this key"? References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> <4A003D23.1070208@fifthhorseman.net> In-Reply-To: <4A003D23.1070208@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 5/5/09 15:20, Daniel Kahn Gillmor wrote: > On 05/05/2009 02:58 AM, Ian G wrote: >> Simplify, simplify, simplify. One hash is good enough >> for 99.99% of the users, and the rest should be implementing not >> eulogising. > [...] >> If it was updated today for IETF, it would say: always insist on the >> right to variations in protocols, for future-proofing. > > I've seen you express this sentiment before, Ian, and i can appreciate > where you're coming from. Variable ciphers and digests are messy, > difficult to get right, and alienating arcana to most users. And, anything that slows users slows usage. Unusability is the killer, not the number of bits in the algorithm. > But i > don't understand what your concrete proposal is here. > > Say OpenPGP had Just One Hash, and it was SHA-1 -- what would be the > best approach for us 0.01% of the users/implementors to take in response > to the news that SHA-1's collision-resistance was insufficient against > well-resourced organizations, and seems likely to get worse before SHA-3 > is settled? Wait until SHA-3. Meanwhile, design how to use SHA-3 from 2012 to 2022. The predictions of the end of the world are premature. Note that nobody has stolen money through an MD5 as yet, and nobody has stolen money because of an RSA-512, either. Nor, has 40 bit secret keys been embarrassed as yet. (All my humble opinion of course :) The business problem here is that the crypto guys are far too far away from the real business to realise that business leakages are around the 50-80% level. In such an environment, nobody much cares about the difference between 99.99 and 99.999%. > How would we help facilitate the transition for the 99.99% of the users > to a safer hash? Or would we simply tell them "OpenPGP is done, go find > something else before the year is up if you want to maintain > private/authenticated communications"? I think it is best treated as a complete transition from packet types. E.g., "It's time to create a complete new key. V5 is ready." With not as much compatibility between the types as expected, but facilitated by tools. Once per decade. A bit like the transition from 2.6 to 5.0 if you recall. Again, what I believe, others think differently. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45M17Ng079837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:01:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45M17xm079836; Tue, 5 May 2009 15:01:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45M0tjZ079809 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 5 May 2009 15:01:07 -0700 (MST) (envelope-from kloecker@kde.org) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KJ6004QSYHI11C0@mta-1.ms.rz.RWTH-Aachen.de> for ietf-openpgp@imc.org; Wed, 06 May 2009 00:00:54 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.40,299,1238968800"; d="asc'?scan'208";a="10826999" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 06 May 2009 00:00:54 +0200 Received: from [192.168.0.161] ([unknown] [78.49.118.14]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KJ600C6VYHI4X20@relay-auth-1.ms.rz.rwth-aachen.de> for ietf-openpgp@imc.org; Wed, 06 May 2009 00:00:54 +0200 (CEST) From: Ingo =?iso-8859-1?q?Kl=F6cker?= To: IETF OpenPGP Working Group Subject: Re: Non-SHA-1 fingerprints Date: Wed, 06 May 2009 00:00:42 +0200 User-Agent: KMail/1.9.10 References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> In-reply-to: Content-type: multipart/signed; boundary=nextPart51737562.EtnubJnk9m; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit Message-id: <200905060000.49934@thufir.ingo-kloecker.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart51737562.EtnubJnk9m Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 05 May 2009, David Shaw wrote: > On May 4, 2009, at 6:04 PM, Daniel A. Nagy wrote: > > Also, since mobile phones typically have a numeric keypad, it would > > be nice if > > fingerprints and key IDs were numeric-only. It is an increasingly > > important > > platform for OpenPGP, I believe. > > I think that is a good point and a great idea, but the only reason > that fingerprints and key IDs are printed in hex now is tradition. > There is nothing in the standard one way or another about how humans > should consume fingerprints. You could even do it with the current > V4 fingerprints: just as my key fingerprint is > 7D92FD313AB6F3734CC59CA1DB698D7199242560 in hex, it is equally > correct as 716901811312187285520504099705403090347495794016 in > decimal. The big problem I see here is that's it's an awfully long > number to type into a mobile keypad. Right. I do already have a hard time typing an unknown phone number with=20 8 digits. Since most mobile phones come with a camera nowadays the way to go is to=20 take a picture of the fingerprint and then run some OCR on the picture.=20 In fact, it would be much better to encode the fingerprint in some kind=20 of easily scanable bar code (additionally to the common hex=20 fingerprint) than as long string of numbers (similar to Semapedia). Regards, Ingo P.S.: The mailing list software does not add a List-Post header (which=20 is used for "Reply to List" by my MUA). Is it possible to fix this? --nextPart51737562.EtnubJnk9m Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkoAtxEACgkQGnR+RTDgudiL5wCeL/YZtGQDctzOV8pBcxtZ4g+0 zeAAnA/MlL6QnAcjUcWwIP6GBmCQF0XQ =M/gC -----END PGP SIGNATURE----- --nextPart51737562.EtnubJnk9m-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45LVCRU077932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 14:31:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45LVCSx077931; Tue, 5 May 2009 14:31:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45LV1Gl077919 for ; Tue, 5 May 2009 14:31:11 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 9C6E92E118 for ; Tue, 5 May 2009 14:31:54 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 43121-01 for ; Tue, 5 May 2009 14:31:49 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id D8CBC2E1D3 for ; Tue, 5 May 2009 14:31:49 -0700 (PDT) Received: from [10.0.2.2] ([69.255.118.244]) by keys.merrymeet.com (PGP Universal service); Tue, 05 May 2009 14:30:56 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 05 May 2009 14:30:56 -0700 Cc: OpenPGP Working Group Message-Id: <12A3741B-5277-45CF-8D53-764CEA5732AD@callas.org> From: Jon Callas To: Daniel Franke In-Reply-To: <87eiv3cq9a.fsf@feanor.dfranke.us> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: I don't think that collides the way you think it does Date: Tue, 5 May 2009 14:30:49 -0700 References: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> <87eiv3cq9a.fsf@feanor.dfranke.us> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 5, 2009, at 12:18 PM, Daniel Franke wrote: > * PGP Signed by an unknown key > > Jon Callas writes: > >> Adi Shamir has pointed out for years now that no one has found *any* >> first or second preimage collision for SHA1. I'll shill for him here. >> >> The new results for 2^52 work, assuming it's actually doable, are >> still for migrating a bitstring into two dependent bitstrings that >> collide. This has significance for people who run CAs with sequential >> serial numbers, or who want to tweak PDFs to project the future, or >> create binary distributions that have and do not have malware. It's >> serious *for* *those* *and* *similar* *cases*. > > I think you mean "no one has found any first or second preimage > *attacks* for SHA-1". To the best of my knowledge, nobody has found > any > SHA-1 collisions at all, either chosen or otherwise. The 2^52 > result is > still theoretical, because while 2^52 hash operations is tractable > for a > WFO, it's still a formidable amount of work, and Cameron McDonald is > not > a WFO. Thank you for the further clarification. You are correct. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFKALAQsTedWZOD3gYRAtQVAJ9bLVO5G5yS5oiCWb5KbWCGibNsEACeMwb3 B/qMAwa5oxwg1q7DJ/aXuww= =OUoa -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45JJ0aj068139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 12:19:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45JJ0tr068138; Tue, 5 May 2009 12:19:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45JIne1068119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2009 12:19:00 -0700 (MST) (envelope-from dfranke@feanor.dfranke.us) Received: from adsl-99-175-103-55.dsl.pltn13.sbcglobal.net ([99.175.103.55] helo=feanor.dfranke.us) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1M1QAC-000JTw-Fb; Tue, 05 May 2009 19:18:48 +0000 Received: by feanor.dfranke.us (Postfix, from userid 1000) id 096162D63ED; Tue, 5 May 2009 12:18:47 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 99.175.103.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+YEYY4vsbGMT1XhnwWCUwL DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dfranke.us; s=default; t=1241551127; bh=1FTDtm8GZXh7vDqToK08D1pw4d9PzmoVhBo4cTFtJPI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=yo9jWthLVI5RfjTIoCbAT41XS7CAXbifwxXCc TO/HcceMlVGLv2Q6FTUVAJn+Sfel9GJia7umKhwYrK/BeZi9PwRS/9fwWm4hpgmuioW Pjne0T4m7rcTTo97jZEvt+HRTLTWDny0Xe0mHVhZAwEOOI98GQmOIY6nivZjGileUVY = From: Daniel Franke To: Jon Callas Cc: OpenPGP Working Group Subject: Re: I don't think that collides the way you think it does References: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> X-Hashcash: 1:26:090505:ietf-openpgp@imc.org::FWfm+2gA8G6xCEMY:000000000000000000000000000000000000000003UWa X-Hashcash: 1:26:090505:jon@callas.org::h6ykG/NGawgQKom8:000BNMG Date: Tue, 05 May 2009 12:18:41 -0700 In-Reply-To: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> (sfid-20090505_110311_348312_3F415D8B) (Jon Callas's message of "Tue, 5 May 2009 10:58:14 -0700") Message-ID: <87eiv3cq9a.fsf@feanor.dfranke.us> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Transfer-Encoding: quoted-printable Jon Callas writes: > Adi Shamir has pointed out for years now that no one has found *any*=20=20 > first or second preimage collision for SHA1. I'll shill for him here. > > The new results for 2^52 work, assuming it's actually doable, are=20=20 > still for migrating a bitstring into two dependent bitstrings that=20=20 > collide. This has significance for people who run CAs with sequential=20= =20 > serial numbers, or who want to tweak PDFs to project the future, or=20=20 > create binary distributions that have and do not have malware. It's=20=20 > serious *for* *those* *and* *similar* *cases*. I think you mean "no one has found any first or second preimage *attacks* for SHA-1". To the best of my knowledge, nobody has found any SHA-1 collisions at all, either chosen or otherwise. The 2^52 result is still theoretical, because while 2^52 hash operations is tractable for a WFO, it's still a formidable amount of work, and Cameron McDonald is not a WFO. Preimage attacks are hard. Even long, long-ago deprecated hash functions have held up well agaist them. The one in the worst shape is MD2, and that attack requires 2^104 operations (vs. 2^128 brute force). I'm pretty confident that by the time there's a computer that can do 2^104 of anything, nobody is going care about my secrets. Here's a threat model I suggest for future work on OpenPGP: assume that the hash function is ideal, but that the adversary has an oracle that takes as input two messages and pointers to n/2 bits of each message (where n is the digest length), and outputs colliding messages by filling in those bits. In other words, preimage attacks are impossible (short of brute force), but birthday attacks are trivial. I think securing OpenPGP against this threat model is possible. As you and others have already pointed out, most of OpenPGP's uses of hash functions already depend only on one-wayness. =2D-=20 Daniel Franke df@dfranke.us http://www.dfranke.us |----| =3D|\ \\\\=20=20=20=20 || * | -|-\--------- Man is free at the instant he wants to be.=20 -----| =3D| \ /// --Voltaire --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iF4EAREKAAYFAkoAkREACgkQ8tqcOcPA7qPwzQD+KPhUId+raki0OX9bx7ulEvKF WfATtLN2BUgdNFJfjg0A/1668CZF1Jw0mkApDGqf3KNRs4LIsvzmpbobvqNTWiX4 =sZo9 -----END PGP SIGNATURE----- --=-=-=-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45HwP69062007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 10:58:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45HwPBM062006; Tue, 5 May 2009 10:58:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45HwOvD062000 for ; Tue, 5 May 2009 10:58:25 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id BABA52E215 for ; Tue, 5 May 2009 10:59:17 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 41539-07 for ; Tue, 5 May 2009 10:59:11 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id ACA3C2E118 for ; Tue, 5 May 2009 10:59:11 -0700 (PDT) Received: from [10.0.2.2] ([69.255.118.244]) by keys.merrymeet.com (PGP Universal service); Tue, 05 May 2009 10:58:18 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 05 May 2009 10:58:18 -0700 Message-Id: <9733A129-5090-4928-A192-C0F1B162B8D5@callas.org> From: Jon Callas To: OpenPGP Working Group Mime-Version: 1.0 (Apple Message framework v930.3) Subject: I don't think that collides the way you think it does Date: Tue, 5 May 2009 10:58:14 -0700 X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adi Shamir has pointed out for years now that no one has found *any* first or second preimage collision for SHA1. I'll shill for him here. The new results for 2^52 work, assuming it's actually doable, are still for migrating a bitstring into two dependent bitstrings that collide. This has significance for people who run CAs with sequential serial numbers, or who want to tweak PDFs to project the future, or create binary distributions that have and do not have malware. It's serious *for* *those* *and* *similar* *cases*. It does *not* mean that you can get a collision on an existing signature, nor on an existing fingerprint, nor on an MDC, etc. We are still sitting at *zero* first and second preimage collisions. I think that we should push through the generic fingerprint proposal. I sorta-kinda picked up the ball on that to work with Derek, but if there's anyone else who wants it (or who wants to co-author with Derek and me), I'm happy to have less work to do. I also think it's completely reasonable for an implementation to back away from SHA1 with all due speed -- but you're supposed to be doing that by 2010, anyway! Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFKAH46sTedWZOD3gYRAgw4AKD+McI0GJOGcFXk/n7gmY0PYsKO0ACfa0DQ zhTAaqwStSUApOg8EoG9Tuk= =s+6q -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45HiRBZ061317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 10:44:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45HiRHw061316; Tue, 5 May 2009 10:44:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45HiGsO061306 for ; Tue, 5 May 2009 10:44:26 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 824882E1D3 for ; Tue, 5 May 2009 10:45:08 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 41465-05 for ; Tue, 5 May 2009 10:45:03 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id E8FF42E118 for ; Tue, 5 May 2009 10:45:03 -0700 (PDT) Received: from [10.0.2.2] ([69.255.118.244]) by keys.merrymeet.com (PGP Universal service); Tue, 05 May 2009 10:44:10 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 05 May 2009 10:44:10 -0700 Message-Id: <318A09AF-96C2-4A2A-8692-F579BCA15568@callas.org> From: Jon Callas To: OpenPGP Working Group In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: New results against SHA-1 Date: Tue, 5 May 2009 10:43:57 -0700 References: X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 4, 2009, at 7:46 PM, Peter Gutmann wrote: > > Daniel Kahn Gillmor writes: > >> What do other folks think? > > Given that the MDC is a hash of plaintext that's then encrypted, and > the hash > value is itself encrypted, I'm not losing any sleep over it. The > hash attacks > so far have required bit-for-bit carefully-chosen plaintext with > known hash > values, not unknown (or even partially-known) plaintext with an > unknown hash > value. I'm not losing a lot of sleep over it, either. The point of the MDC is to provide a low-level integrity check. There's an easy high-level integrity check, a digital signature. The MDC exists for people who don't want to sign, but do want more protection than naked CFB mode, which is completely vulnerable to truncation. The construction we use is not "secure". I put scare quotes around it for a reason. In particular, it's vulnerable to existential forgeries. However, every spam in the world is an existential forgery, and if you wanted to send an MDC forgery to someone, it's much easier to just write the message and encrypt it to them than modifying an existing message. What that means is that while there are some protocols that really have to worry about existential forgeries (like IPsec), we're really not one of them, especially since there's always signing for us. In 4880, we described how one might upgrade the MDC. If someone believes it's important, I would support anyone writing a draft for an upgraded MDC. (But as an implementer, I can't make a statement as to when or if PGP would implement it.) Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFKAHrqsTedWZOD3gYRAo0BAJ4maMvMTEHDIiJBQ+ry3VuUt3gW7gCglCkE 0nX3EUzYQ+alsPjef8RSeE4= =Tq6M -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45Gj43A056300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 09:45:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45Gj3Wc056299; Tue, 5 May 2009 09:45:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45GipDR056268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 May 2009 09:45:03 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 83D7814F6E1; Tue, 5 May 2009 08:03:00 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Non-SHA-1 fingerprints Message-Id: <20090505150300.83D7814F6E1@finney.org> Date: Tue, 5 May 2009 08:03:00 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 05/04/2009 06:04 PM, Daniel A. Nagy wrote: > For fingerprints, MDC and self-signatures, collision-resistance does > not matter, only the one-way property. So I think it is totally safe to > postpone discussion until SHA3 is selected. To quibble a bit, the real issue is not the specific usage, but whether the creator of the signature controls the content that is hashed, and whether he adds enough information and "entropy" of his own that no outsider could substantially control and/or guess the content. I can imagine situations from the list above where outsiders might be able to mount an attack. Even self-signatures may have substantial data contributed by outsiders, at least with use of some allowed extensions. We have notation subpackets and possibly other subpackets which could include data that is supplied by outsiders. PGP has for many years supported an extension to the User ID called a Photo ID, which includes a picture of the key holder. Imagine if you added to your key a photo of yourself, but one that was taken by someone else, and signed it with a self signature using a weak hash. Some time later you might discover a different-looking photo circulating, signed with that same signature (because the photo was gimmicked to allow a change in some data to display a different image). One could imagine security implications of this kind of substitution. MDC packets should be immune because we hash the prefix which should normally include 128+ bits of randomness. Likewise with fingerprints, presumably the key itself includes sufficient randomness to make it unguessable, otherwise many other attacks are possible. Hal Finney PGP Corporation Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DJqG2037350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 06:19:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45DJq7E037349; Tue, 5 May 2009 06:19:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n45DJfl1037327 for ; Tue, 5 May 2009 06:19:52 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 10420 invoked from network); 5 May 2009 13:19:39 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay02.pair.com with SMTP; 5 May 2009 13:19:39 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <4A003D23.1070208@fifthhorseman.net> Date: Tue, 05 May 2009 09:20:35 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: how to specify "trust no signatures over hash X from this key"? References: <49FFBB0B.9070209@fifthhorseman.net> <49FFE3B2.9060408@systemics.com> In-Reply-To: <49FFE3B2.9060408@systemics.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig171F5511815A85E73F57BC1D" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig171F5511815A85E73F57BC1D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2009 02:58 AM, Ian G wrote: > Simplify, simplify, simplify. One hash is good enough > for 99.99% of the users, and the rest should be implementing not > eulogising. [...] > If it was updated today for IETF, it would say: always insist on the > right to variations in protocols, for future-proofing. I've seen you express this sentiment before, Ian, and i can appreciate where you're coming from. Variable ciphers and digests are messy, difficult to get right, and alienating arcana to most users. But i don't understand what your concrete proposal is here. Say OpenPGP had Just One Hash, and it was SHA-1 -- what would be the best approach for us 0.01% of the users/implementors to take in response to the news that SHA-1's collision-resistance was insufficient against well-resourced organizations, and seems likely to get worse before SHA-3 is settled? How would we help facilitate the transition for the 99.99% of the users to a safer hash? Or would we simply tell them "OpenPGP is done, go find something else before the year is up if you want to maintain private/authenticated communications"? Regards, --dkg --------------enig171F5511815A85E73F57BC1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSgA9KMzS7ZTSFznpAQoSJQ/7Bf2xRQQm1NLLSSK2xTBJYpRgPJb/PqNr ZBNcu1jyWJPNaAqnQpZIjpepFCO188qmnIgmwalQs8zvnDpn459ftEu12cb3Y5no Pf9sD8B2ufhhGNmDR84IjM/HQeRYgJ2ooeU/VqCnSGyQfZuQI7bvIi7U/KCu2j4J IN0ynMDOMES/CwLicf1IIYtO+QQjoRrATacBqOU92sQHpG74a2lEqx7nxSr+8l5S DyR3dn2jD4hvl3bhuHaoyUqm/0FQqElN/XuXwXU9IMyl1KrF3Da46SxrvGg8+z/1 PPtkcDLNrgpPioEj8XvUSM8BGqHFMYfwwe25IPInfdYoobvPse0KpreCPdZeBBbO /PljMfzqsRjomS19ogybe1TJ9dvoOnUluQxnDj88ydsfAFpNJg8qIE8x1u9IeLjC 0uwjQY5isXdoJpYKyI7/iOL3rKiu7v5V5RTuwwC/w32vPBWi3XCB9KysHBVQQmQC 6AmKijmMJfJcVUY6RoTykhV6Cfg/vBg3AzUMv/9Pxw7QniHbVVQDGzw4CMlk4joC NuV8s6sJb/TpT573bb/mRRMctvIu1jvsv/YzVV/paA/E4PGVUGYoBMSX7MNgeIdE P1tzqcGpiwbDEMywSHX6SdM3ya4qa9ORpo4MdbhgRwFdDwblUy7BwjYVtSSV9n/n 7xubhRlV9m0= =CyQN -----END PGP SIGNATURE----- --------------enig171F5511815A85E73F57BC1D-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45BbI71029558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 04:37:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45BbIwX029557; Tue, 5 May 2009 04:37:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45Bb65o029539 for ; Tue, 5 May 2009 04:37:17 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.63 #1 (Debian)) id 1M1IxN-00014O-2J for ; Tue, 05 May 2009 13:37:05 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1M1Ioo-0000B5-QN; Tue, 05 May 2009 13:28:14 +0200 From: Werner Koch To: "Daniel A. Nagy" Cc: David Shaw , IETF OpenPGP Working Group Subject: Re: Changing GPG's default key type References: <06737077-FE52-404C-A540-25076B3A8162@jabberwocky.com> <49FFDCEF.5040006@epointsystem.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 05 May 2009 13:28:14 +0200 In-Reply-To: <49FFDCEF.5040006@epointsystem.org> (Daniel A. Nagy's message of "Tue, 05 May 2009 08:30:07 +0200") Message-ID: <87r5z394c1.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110011 (No Gnus v0.11) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 5 May 2009 08:30, nagydani@epointsystem.org said: > There is, however, no known workaround for #2. Generating a PGP-compliant > 1024-bit RSA key on NOKIA 3410 takes at least 20 minutes. More than enough to That is a problem of that implementation. Even 10 year old smartcards are able to generate a 1k RSA key in less than 30 seconds. Modern cards are much faster. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n457H46S011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 00:17:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n457H4Oi011599; Tue, 5 May 2009 00:17:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n457H2NR011592 for ; Tue, 5 May 2009 00:17:03 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.63 #1 (Debian)) id 1M1Etg-0005eF-Uh for ; Tue, 05 May 2009 09:17:00 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1M1Elx-0008Pk-QI for ; Tue, 05 May 2009 09:09:01 +0200 From: Werner Koch To: IETF OpenPGP Working Group Subject: Re: New results against SHA-1 References: <9D828E6C-482D-4AC1-B56F-F3DF3D02E4C7@jabberwocky.com> <49FF0A74.5030805@fifthhorseman.net> <87iqkgbwff.fsf@wheatstone.g10code.de> <49FF325A.80106@fifthhorseman.net> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 05 May 2009 09:09:01 +0200 In-Reply-To: <49FF325A.80106@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 04 May 2009 14:22:18 -0400") Message-ID: <87fxfk9gc2.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110011 (No Gnus v0.11) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 4 May 2009 20:22, dkg@fifthhorseman.net said: > Another approach would be to formally prefer digest algorithms that do > not exhibit the same single-pass behavior of SHA-1 -- is that feasible? No. Single pass processing an important feature. Anything else can only be done if the required amount of RAM is small enough and with an upper limit to be implemented on small devices. Think of a network proxy with no need to store the data passing through but to verify signatures of large chunks of this data. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4577FhN010922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 00:07:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4577F4R010920; Tue, 5 May 2009 00:07:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45772lu010902 for ; Tue, 5 May 2009 00:07:13 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.63 #1 (Debian)) id 1M1Ek0-0005ZZ-Hs for ; Tue, 05 May 2009 09:07:00 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1M1Ecn-0008P5-QE for ; Tue, 05 May 2009 08:59:33 +0200 From: Werner Koch To: IETF OpenPGP Working Group Subject: Re: Fix revocation keys instead of fingerprints? References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> <49FFA92E.50100@fifthhorseman.net> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 05 May 2009 08:59:33 +0200 In-Reply-To: <49FFA92E.50100@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 04 May 2009 22:49:18 -0400") Message-ID: <87k54w9gru.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110011 (No Gnus v0.11) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 5 May 2009 04:49, dkg@fifthhorseman.net said: > realistic keys out there right now are still only around 1KB of a > subpacket, and revocation key subpackets themselves are pretty rare. So > the added size doesn't seem problematic to me. I concur. In fact the forthcoming default of RSA signatures will increase the size of a keyblock far more than a single longer revocation key subpacket. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456xHgS010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 23:59:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n456xHTu010462; Mon, 4 May 2009 23:59:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp01.uk.clara.net (netscalibur-outbound-smtp01.uk.clara.net [213.253.59.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456x6Qx010442 for ; Mon, 4 May 2009 23:59:17 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:6543) by relay01.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.41]:1325) with esmtp id 1M1EcK-00005d-65 (Exim 4.69) (return-path ); Tue, 05 May 2009 07:59:04 +0100 Received: from ip80-101-239-120.hotspotsvankpn.com (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 4F1915D65; Tue, 5 May 2009 07:58:58 +0100 (GMT/BST) Message-ID: <49FFE3B2.9060408@systemics.com> Date: Tue, 05 May 2009 08:58:58 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: how to specify "trust no signatures over hash X from this key"? References: <49FFBB0B.9070209@fifthhorseman.net> In-Reply-To: <49FFBB0B.9070209@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 5/5/09 06:05, Daniel Kahn Gillmor wrote: > Is there interest in being able to explicitly state such a policy? None whatsoever. Simplify, simplify, simplify. One hash is good enough for 99.99% of the users, and the rest should be implementing not eulogising. Has anyone read the OSS Guide to Sabotage? In there it has a list of things about how to break up a user group. One of them is to insist on following rules because they are important, another advice is to always refer things to a committee. If it was updated today for IETF, it would say: always insist on the right to variations in protocols, for future-proofing. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456UBAF009026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 23:30:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n456UB90009024; Mon, 4 May 2009 23:30:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456UAmk009017 for ; Mon, 4 May 2009 23:30:10 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 2E26131A590; Tue, 5 May 2009 08:30:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 0A566598099; Tue, 5 May 2009 08:30:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n5iGA7C1kZE4; Tue, 5 May 2009 08:30:08 +0200 (CEST) Received: from [10.0.0.232] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id AFBF6598091; Tue, 5 May 2009 08:30:08 +0200 (CEST) Message-ID: <49FFDCEF.5040006@epointsystem.org> Date: Tue, 05 May 2009 08:30:07 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: David Shaw CC: IETF OpenPGP Working Group Subject: Re: Changing GPG's default key type References: <06737077-FE52-404C-A540-25076B3A8162@jabberwocky.com> In-Reply-To: <06737077-FE52-404C-A540-25076B3A8162@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigADA531ADE781892CA88A4D27" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADA531ADE781892CA88A4D27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is one reason why I still use DSA keys in some of my applications: They are much cheaper to generate. I strongly believe that in order for c= rypto to become ubiquitous, it is important that key pairs are generated right = after installation. In case of RSA, it can go wrong in two ways: 1. RSA requires too many random bits and a computer that nobody touches c= an just freeze up waiting for random input. 2. The time to generate an RSA key is too long on cheap embedded hardware= =2E Of course, neither is of concern for GPG's default key; if you have such = a system, just tell it to generate DSA keys. But these two points should be= kept in mind. The obvious workaround for #1, is to read enough random bits for the secu= rity of the key (e.g. 256) and then seed a secure PRNG with them. There is, however, no known workaround for #2. Generating a PGP-compliant= 1024-bit RSA key on NOKIA 3410 takes at least 20 minutes. More than enoug= h to make casual users frustrated and throw away the whole thing. Now, of cour= se, such slow mobiles are not manufactured anymore, but even 2 minutes is unacceptable, which is the norm for today's low-end phones. And since the= market values battery life much more than computational muscle (low-end phones = are very responsive at present clock rates) in mobiles, this is not going to = improve too rapidly. --=20 Daniel --------------enigADA531ADE781892CA88A4D27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkn/3O8ACgkQoeH/BzqmYjjujwCgkC5EGQtwYoAEwNY4VKHYgooT hucAnjsB9OKhKWCBo3YQQalaUt55QBmF =4lhF -----END PGP SIGNATURE----- --------------enigADA531ADE781892CA88A4D27-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456HrEM008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 23:17:53 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n456Hr1k008483; Mon, 4 May 2009 23:17:53 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456HquA008477 for ; Mon, 4 May 2009 23:17:52 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 4346811A972 for ; Tue, 5 May 2009 08:17:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 26873598099 for ; Tue, 5 May 2009 08:17:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Wbp6SqEfRbcG for ; Tue, 5 May 2009 08:17:49 +0200 (CEST) Received: from [10.0.0.232] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id D457A598091 for ; Tue, 5 May 2009 08:17:48 +0200 (CEST) Message-ID: <49FFDA0C.6040900@epointsystem.org> Date: Tue, 05 May 2009 08:17:48 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: Non-SHA-1 fingerprints References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <49FFA8C0.70306@fifthhorseman.net> In-Reply-To: <49FFA8C0.70306@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7486F63840E3487114A61F7A" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7486F63840E3487114A61F7A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your reasoning below is correct, as far as I can tell. Daniel Kahn Gillmor wrote: > On 05/04/2009 06:04 PM, Daniel A. Nagy wrote: >> For fingerprints, MDC and self-signatures, collision-resistance does n= ot matter, >> only the one-way property. So I think it is totally safe to postpone d= iscussion >> until SHA3 is selected. >=20 > The more that i consider this, the more important it seems. Thank you > for emphasizing it, Daniel. >=20 > If i understand you correctly, your point is that fingerprints and > self-signatures use hashes over data that is provided entirely by the > signer, covering nothing that is supplied by an outside party. >=20 > Since "birthday" attacks rely on the attacker generating an arbitrary > collision, providing one side of it for signing by the victim, and then= > transferring the signature onto the other side of the discovered > collision, they do not work against material under full control of the > signer (like fingerprints and self-sigs). >=20 > Even if the recent claims of O(2^52) (instead of the > theoretically-optimal 2^80) operations to generate a colliding pair wer= e > to scale proportionally to attacks against the one-wayness of SHA-1, > that would mean O(2^104) (instead of 2^160) operations to find a messag= e > that hashes to a given value. i have no idea if these sort of results > can actually scale this way, but i imagine we'd hear a much larger > hullabaloo if someone had announced an attack against the one-wayness > of SHA-1 with less than O(2^104) operations. >=20 > Anyway, since 2^104 is still outside the capabilities of well-funded > organizations, we have breathing room on these parts of the > specification that only rely on collision-resistance. >=20 > Did i get anything wrong above? I apologize if this is elementary for > everyone else, i'm just trying to make sure i understand the ideas invo= lved. >=20 > --dkg >=20 --------------enig7486F63840E3487114A61F7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkn/2gwACgkQoeH/BzqmYjgKNwCg3933RhIsA85EMI+lhIoMv6LO kIIAoLq19Ms4RZH8vLqgVaK0vcfwf91s =3hVN -----END PGP SIGNATURE----- --------------enig7486F63840E3487114A61F7A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456FhxB008363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 23:15:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n456Fhn0008362; Mon, 4 May 2009 23:15:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456FWEx008349 for ; Mon, 4 May 2009 23:15:42 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 7067D11A9BC for ; Tue, 5 May 2009 08:15:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 12992598099 for ; Tue, 5 May 2009 08:15:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DIY3oRhoJPCf for ; Tue, 5 May 2009 08:15:29 +0200 (CEST) Received: from [10.0.0.232] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id BD5EB598091 for ; Tue, 5 May 2009 08:15:29 +0200 (CEST) Message-ID: <49FFD981.3030501@epointsystem.org> Date: Tue, 05 May 2009 08:15:29 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: decimal fingerprints [was: Re: Non-SHA-1 fingerprints] References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <49FF94D4.3030101@fifthhorseman.net> In-Reply-To: <49FF94D4.3030101@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC704609DD70F977B4CBDADD5" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC704609DD70F977B4CBDADD5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, it is not the fingerprint, but the key ID that is typed in, but= it is a NICE feature of OpenPGP at present that the key ID is simply a substrin= g of the fingerprint. I would hate to lose that. Daniel Kahn Gillmor wrote: > On 05/04/2009 08:17 PM, David Shaw wrote: >> On May 4, 2009, at 6:04 PM, Daniel A. Nagy wrote: >> >>> Also, since mobile phones typically have a numeric keypad, it would b= e >>> nice if >>> fingerprints and key IDs were numeric-only. It is an increasingly >>> important >>> platform for OpenPGP, I believe. >> I think that is a good point and a great idea, but the only reason tha= t >> fingerprints and key IDs are printed in hex now is tradition. There i= s >> nothing in the standard one way or another about how humans should >> consume fingerprints. You could even do it with the current V4 >> fingerprints: just as my key fingerprint is >> 7D92FD313AB6F3734CC59CA1DB698D7199242560 in hex, it is equally correct= >> as 716901811312187285520504099705403090347495794016 in decimal. The b= ig >> problem I see here is that's it's an awfully long number to type into = a >> mobile keypad. >=20 > How often does anyone type in a fingerprint at all? My impression of > the typical workflow is: >=20 >=20 > * read fingerprint from physical media (business card, scrap of paper,= etc) >=20 > * search for a key from the public keyservers (usually by User ID). >=20 > * scan list of results for a key with a matching keyid (truncated > fingerprint) >=20 > * fetch selected key from keyserver >=20 > * view/double-check fingerprint of fetched key againt physical media >=20 > In this workflow, the only typing done is to enter the user id to searc= h > for (and even that is not always needed on a mobile device, because the= > person searched for is may already be in the address book for other > contacts). if the fingerprint is entered, it's often only the truncate= d > keyid, which is guaranteed to be much smaller than the fpr in any case.= >=20 > Making this change to the fingerprint presentation seems huge: are > people expected to change all their business cards, .sigs, web sites, > etc. to show both styles of fingerprint? or to completely transition t= o > the new style? in terms of truncated fingerprints (keyids), how are we= > to distinguish between the ones which currently have only digits 0-9 in= > hex and decimal-style fingerprints? This seems like a very costly > tradeoff for the sake of thumbing in 8 decimal characters instead of 8 > hex digits. >=20 > --dkg >=20 --------------enigC704609DD70F977B4CBDADD5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkn/2YEACgkQoeH/BzqmYjhMqgCdGkyMIaZiWDsVXO3zwgaOwRbX bpIAmgMAa48AYJM0yAeODejfeezxegtw =boiH -----END PGP SIGNATURE----- --------------enigC704609DD70F977B4CBDADD5-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456EH9E008283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 23:14:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n456EHQM008282; Mon, 4 May 2009 23:14:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n456E5ac008275 for ; Mon, 4 May 2009 23:14:16 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 4968431A8C0; Tue, 5 May 2009 08:14:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 234EC598099; Tue, 5 May 2009 08:14:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CYSw8j1xOjfC; Tue, 5 May 2009 08:14:03 +0200 (CEST) Received: from [10.0.0.232] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id CD7E7598091; Tue, 5 May 2009 08:14:03 +0200 (CEST) Message-ID: <49FFD926.20802@epointsystem.org> Date: Tue, 05 May 2009 08:13:58 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: David Shaw CC: IETF OpenPGP Working Group Subject: Re: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fingerprints) References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> In-Reply-To: <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF756CAA244F068AD36E04778" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF756CAA244F068AD36E04778 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, David Shaw wrote: > It's a larger problem than just fingerprints. We also use a fingerprin= t > as a specifier inside the revocation key subpacket, to designate which > key can be used to issue revocations on our behalf. The thing is, > though, a fingerprint isn't really a very good revocation key specifier= : >=20 > Fingerprints: > * Must be human-readable > * Needs to be small to be useful > * Can collide to some small amount (4880 even documents that they > collide in section 12.2) That's not the fingerprint. That's the key ID. > Revocation key specifier: > * Does not need to be human-readable > * Has much looser size requirements (shouldn't be enormous, but > certainly can be bigger than 160 bits without hurting anything) > * Should never collide (we don't want the wrong key being able to revok= e > our key) In case of collision, both colliding pre-images are done by the same enti= ty. > Perhaps we'd do better by leaving fingerprints alone and instead fixing= > how we specify revocation keys? There is nothing wrong with them at present. Well, actually, I would argue that revocation is currently over-designed.= Since revocation is an irreversible act, there is no need for the heavy artille= ry of digital signatures for that purpose. All the s2k specifiers used for symm= etric encryption would do (in a hashed sub-packet together with the resulting symmetric key) and inserting a non-hashed sub-packet with a matching revo= cation passphrase into the revoked signature would be just as secure a method fo= r revocation than adding a revocation signature packet. There is no need for asymmetric crypto for revocation. Instead of revocat= ion signatures, it would be perfectly safe to use revocation passphrases. > We could try to come up with a new non-colliding way to disambiguate > keys, but fundamentally, anything that is smaller than the key packet > itself can still collide. Again, collisions are not important in this case. Collisions only matter = when the signed information is compiled by a different entity than the signer.= With a hash that is one-way but not collision resistant, you can do two k= eys that have the same fingerprint. So whay? Both are under your control, a signature with either is your signature. > So instead, why not define a new revocation > subpacket that contains the class octet from the old revocation key, an= d > the rest of the subpacket is simply a copy of the public key packet in > question? It costs more and does not provide any extra security. I mean there is no= attack that can be prevented in this way. Therefore, it is less secure. > I don't mean the whole transferable public key, of course, > just the contents of packet #6. This public key packet doesn't need an= y > self-signatures or anything else like that, as it is implicitly > authenticated by the signature that carries the revocation key subpacke= t. It still makes the key fatter without making any attack more difficult. I= t won't make illegitimate revocation more difficult. --=20 Daniel --------------enigF756CAA244F068AD36E04778 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkn/2SoACgkQoeH/BzqmYjhn+ACfXrHUxacK1Yon5Iwf32CPRY01 TuoAoJIBIlvrFmqoHGhEaIJUMScF93cu =lxIl -----END PGP SIGNATURE----- --------------enigF756CAA244F068AD36E04778-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4544dZA001088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 21:04:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4544dBG001087; Mon, 4 May 2009 21:04:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n4544cMQ001081 for ; Mon, 4 May 2009 21:04:39 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 2495 invoked from network); 5 May 2009 04:04:37 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 5 May 2009 04:04:37 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49FFBB0B.9070209@fifthhorseman.net> Date: Tue, 05 May 2009 00:05:31 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: how to specify "trust no signatures over hash X from this key"? X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6B3E60808F65218637960D5B" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B3E60808F65218637960D5B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As i'm thinking about hash function transitions right now, it occurs to me that i'm not sure how to specify something like "The holder of this key will never issue signatures using digest algorithm $foo" In RFC 4880, section 5.2.3.8 the digest algorithm preferences subpacket says something similar: Message digest algorithm numbers that indicate which algorithms the key holder prefers to receive. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in Section 9. This is only found on a self-signature. But this is semantically something fairly different from stating what kind of use the keyholder expects to pursue. Consider the case where a user has in the past made and published MD5-based signatures, and no longer believes that hash algorithm is secure for the purposes used (or if you like, think into the near future, and imagine the same situation with SHA1). It seems to me that it would be useful to have a way that a keyholder could explicitly state "I no longer make signatures over digest X. Please consider any signatures from this key using digest X to be invalid= =2E" This does lead to the possibility of an explicit "impedance mismatch", where Alice says "I never issue MD5, SHA1, or RIPEMD160 digests" and Bob says "I prefer to receive only SHA1, RIPEMD160, or MD5 digests" -- in this case, Alice's key is useless to Bob. But this impedance mismatch exists implicitly anyway, if these are the actual policies. It seems like it would be useful to know that the conflict exists at that level. Note: *could* a user say "i never issue SHA1 signatures" and remain 4880-compliant? I think so; the spec says that implementations MUST implement SHA1, but it does not say that they must force the user to use it or trust it. Is there interest in being able to explicitly state such a policy? Would this be worth a new subpacket type? If so, would it make sense for ciphers as well as digests? --dkg --------------enig6B3E60808F65218637960D5B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSf+7EMzS7ZTSFznpAQoCJw//QUtCuQnxqrr7uxVqdbi7m9mi3+x9kGwF viuS4Oujpa64RlU0by6nOEA5Cea7SVchrU+GKFhbytvfDQup+kNGIVuMJaNy6bSC e1C3YpXw+kiEwp45Y2214Pzv71MGsbyCOUkXgAroMS8nW0u9zOmgXiEhxYnEAWQJ lFSEBpyBEQMol8nenw95QgnVPI8bztS6S1BJDGo92u3NqehUfnhxheMR+iOd0L5i /rXN8RXOPHzwaob/f15gYNm7B/JJxiXYaMogmKP00FFcNxDh4WFkEYgV0mtMuj0P RewzNZlEBOVP5edZfOzvVRGr/ApVuZJ5C4SeQOa0ZdHypVZyM3djKtiMxyDj1YpS 5AhnpCGEWUOStnphuOtfJtWzDKV9aCc/hvr6r6KBO3xdzKsIJTk+c/LGrp2C3WvZ HbHf5EFuFhNZE8vMGp02ViXrEtWwqgfOATiLK+aNtgmDl8znpRrhq53k2u/Qcq5d Qz64HixsC/UT8CKwVl8ymrRG0juA59L6zHWlJfCiTajHM0SpxWoknIA4mDpC+RwU PujiiRmjTNDVREVM5iQmRm0S0cKzkNku59pUeEYhBJSJ26SpntGf+2xIo4dnwiYU eSeMr4Uh+mPlPzK578KHa9y1zPD8ifp9+zQFWCS55jTqJZrFGheHmB0VAgsnMCId PPHdK7f/6W8= =pCgL -----END PGP SIGNATURE----- --------------enig6B3E60808F65218637960D5B-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4532uJZ098147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 20:02:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4532uMq098146; Mon, 4 May 2009 20:02:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4532jVV098136 for ; Mon, 4 May 2009 20:02:55 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CEE3F9FE85; Tue, 5 May 2009 15:02:44 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWjt9zissPYP; Tue, 5 May 2009 15:02:44 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 582829FB6F; Tue, 5 May 2009 15:02:42 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A88031DE4001; Tue, 5 May 2009 15:02:36 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1M1AvU-0002Fn-HI; Tue, 05 May 2009 15:02:36 +1200 From: Peter Gutmann To: dshaw@jabberwocky.com, jon@callas.org Subject: Re: Changing GPG's default key type Cc: ietf-openpgp@imc.org In-Reply-To: <09C603AC-BEE6-43C4-99D0-08B8F4D0BD61@callas.org> Message-Id: Date: Tue, 05 May 2009 15:02:36 +1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: >Many X.509 systems are like this too -- DSA is the mandatory-to-implement, >but it's not clear that anyone has ever created a DSA certificate outside of >interop testing. Actually even the pretense of that one was dropped a long time ago, no-one apart from the people drafting the standards (and I'm not even sure about them) was ever under any illusion that the de facto standard was anything other than RSA (the PKIX spec still contains DSA signing certs because they were created by NIST more than a decade ago, not because they reflect current practice). People didn't even pretend to do the encryption-algorithm side of things, X9.42 DH, the only implementation I know of that bothered with this was the SFL reference implementation, which didn't have any choice in the matter [0]. Microsoft implemented it as a read-only (i.e. decrypt-only) option specifically to avoid accusations that they didn't comply with the standard, but that was about all. The last time I checked the specs still fudged the matter by saying that you MUST support one of the following shopping-list (including things like MD2 and X9.42), but most implementers know how to interpret this, MUST RSA, WHO-CARES anything else. Peter. [0] So everyone claimed standards compliance without being compliant secure in the knowledge that since no-one else was either, this could never be checked. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n452mMwP097152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 19:48:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n452mMCA097151; Mon, 4 May 2009 19:48:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n452mL4J097145 for ; Mon, 4 May 2009 19:48:21 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 90678 invoked from network); 5 May 2009 02:48:20 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 5 May 2009 02:48:20 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49FFA92E.50100@fifthhorseman.net> Date: Mon, 04 May 2009 22:49:18 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fingerprints) References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> In-Reply-To: <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig107BF823AF3E617747B108F1" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig107BF823AF3E617747B108F1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/04/2009 08:17 PM, David Shaw wrote: > Perhaps we'd do better by leaving fingerprints alone and instead fixing= > how we specify revocation keys?=20 [...] > why not define a new revocation > subpacket that contains the class octet from the old revocation key, an= d > the rest of the subpacket is simply a copy of the public key packet in > question? I don't mean the whole transferable public key, of course, > just the contents of packet #6. This seems like a good strategy to me, and a *much* simpler one than trying to overhaul fingerprints! In fact, this seems like a good idea whether or not fingerprints are overhauled. Are there any objections in the WG to this re-definition of revocation key subpackets? the largest realistic keys out there right now are still only around 1KB of a subpacket, and revocation key subpackets themselves are pretty rare. So the added size doesn't seem problematic to me. --dkg --------------enig107BF823AF3E617747B108F1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSf+pL8zS7ZTSFznpAQoOgQ//aOTc+ap0k3JTCDr+U4ktsFB48PIpIswt YQ6rTV//FOcTzTC9xpf2dB44D83QaC7IN77TLZq4Hu+PWlRsbZ67DRQJ0OBmxKKe i1ytF2O8M6N4EYWqgZwXFUnkybzaGISKNAFTm0N3f7C8bz79JLOWedWYuUmqCwfD AVazdFgbbWaIh+lyTxMl5sKBvkBK3fwFRN1RAZQhF68HEC2sq4aP6t7M3jwfmDUv sJzYerP5pAaWQi7AbO6dXynRMh16lRfGMpBTNlv2Rx3RX51Ll2rquOFVm/4CdrUV McTqH6sESIjTNvtUYs/d3cpXGG1jyXYE/5x+LBP0ovGVgNopA9ZM+DK1ChrzMK4L K6CxsWqXUzqIXaIPZNns7L9PqzMjziE/W6FyDE1MI8RJBLRm7+tXeLessAp3Z7M7 0J8J/eB5pU3eVkiHgpMJ+SjvLssRs4l6xvef9VAblm+ji7YvcECYMp8+OefE6zwy CiwALwg2Yi/KD4H+tdivXt4P1Qzn8FaevWTd5/b6Sq5Ryoztp03E0HyR1WLlr+Cr hnKhZvpQAuA7aw7MsM/GqPyhuGyBZ4ZvpCz9uDzOAc510TDPsY6qJsS1/OAIYVo8 ABiQL8Db5wJEa8pfi79kgOnaAhJUZh0cRxLBZskfYp4qoXITevTxyfSr1OFHEN9h TYy+v5KqJa0= =7grO -----END PGP SIGNATURE----- --------------enig107BF823AF3E617747B108F1-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n452klZ3097054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 19:46:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n452klUQ097053; Mon, 4 May 2009 19:46:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n452kVYg097007 for ; Mon, 4 May 2009 19:46:47 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2EAF61A9A8 for ; Tue, 5 May 2009 14:46:31 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDz6NGCu2qBW for ; Tue, 5 May 2009 14:46:31 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 125091A9A2 for ; Tue, 5 May 2009 14:46:30 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 150651BE4001 for ; Tue, 5 May 2009 14:46:30 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1M1Aft-0001ZO-TZ for ietf-openpgp@imc.org; Tue, 05 May 2009 14:46:29 +1200 From: Peter Gutmann To: ietf-openpgp@imc.org Subject: Re: New results against SHA-1 In-Reply-To: <49FF3EC2.7030504@fifthhorseman.net> Message-Id: Date: Tue, 05 May 2009 14:46:29 +1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Kahn Gillmor writes: >What do other folks think? Given that the MDC is a hash of plaintext that's then encrypted, and the hash value is itself encrypted, I'm not losing any sleep over it. The hash attacks so far have required bit-for-bit carefully-chosen plaintext with known hash values, not unknown (or even partially-known) plaintext with an unknown hash value. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n452kfLt097036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 19:46:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n452kfEK097035; Mon, 4 May 2009 19:46:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n452keiu097028 for ; Mon, 4 May 2009 19:46:41 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 90422 invoked from network); 5 May 2009 02:46:38 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 5 May 2009 02:46:38 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49FFA8C0.70306@fifthhorseman.net> Date: Mon, 04 May 2009 22:47:28 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: Non-SHA-1 fingerprints References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> In-Reply-To: <49FF6677.7070907@epointsystem.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE9C3B898F6A8B9A72D08A57A" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9C3B898F6A8B9A72D08A57A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/04/2009 06:04 PM, Daniel A. Nagy wrote: > For fingerprints, MDC and self-signatures, collision-resistance does no= t matter, > only the one-way property. So I think it is totally safe to postpone di= scussion > until SHA3 is selected. The more that i consider this, the more important it seems. Thank you for emphasizing it, Daniel. If i understand you correctly, your point is that fingerprints and self-signatures use hashes over data that is provided entirely by the signer, covering nothing that is supplied by an outside party. Since "birthday" attacks rely on the attacker generating an arbitrary collision, providing one side of it for signing by the victim, and then transferring the signature onto the other side of the discovered collision, they do not work against material under full control of the signer (like fingerprints and self-sigs). Even if the recent claims of O(2^52) (instead of the theoretically-optimal 2^80) operations to generate a colliding pair were to scale proportionally to attacks against the one-wayness of SHA-1, that would mean O(2^104) (instead of 2^160) operations to find a message that hashes to a given value. i have no idea if these sort of results can actually scale this way, but i imagine we'd hear a much larger hullabaloo if someone had announced an attack against the one-wayness of SHA-1 with less than O(2^104) operations. Anyway, since 2^104 is still outside the capabilities of well-funded organizations, we have breathing room on these parts of the specification that only rely on collision-resistance. Did i get anything wrong above? I apologize if this is elementary for everyone else, i'm just trying to make sure i understand the ideas involv= ed. --dkg --------------enigE9C3B898F6A8B9A72D08A57A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSf+oxczS7ZTSFznpAQr7+RAAoNZqPFaaLFm4/qGyoo/YzQfVi9Vi97JW Mw7JM1XeGm+F2stc1yG8mqBxXr34/0J1wAdI4BLcF6HLnWyI6xZP14YgPb/f1YOe JvseA55NEdS1SC6HXz5uoVdv74sxbyTuLXE69+AzS+mT4bKwU62eVNhrYLgG/zBS 2VWLB/gsOQnWdaQPzh3wX7MU3fYMkZL7O1u1Ixnsfw72kmhQz6sNwlfBQolqL8Bd VCZJztGXUn7KYXy8Q+ndfzPul/GLaUzcIg6CKnlSsb8/YRKffABRowa7zbkRT3Cd E2/ges0hmtMOmvYe7/4v9Vtl/MxuUBMPV4D7TvjATJsDHdM84DVi30wpzTEWLkdK 2spzRXUScXbOpAq9g4/+idgCQ2/AOr4VduHEYw+mIGdue2aB3ubNFFhxkNM12iX3 vbUT1uAmfkLgyGfQIUSK36EJLy45hSKkBhqlWzr8L3Byu3Tb65/17PVvS1uyEI4b cy7iLvJGuHW057xxkMvk1cEEYIYz7hn1XpHGd+XxZQyOBkjR78c0Qfmf0dvCv9HS /3lfUThuIJohDK7AkCKPZRDh1NfdKO24WF31kM7yWsKSufP5GzOSEYMVsqZllQ+9 h5ORvZtSdV9u/prCA67CcSRuHauHhKCZHZFHx9iZimhuJyTBzy3FhW8FIPMfQRtT bMgvtN6iLtg= =5ffQ -----END PGP SIGNATURE----- --------------enigE9C3B898F6A8B9A72D08A57A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n451Lkkd092530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 18:21:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n451LkLD092529; Mon, 4 May 2009 18:21:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n451LYAX092518 for ; Mon, 4 May 2009 18:21:45 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 76223 invoked from network); 5 May 2009 01:21:34 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 5 May 2009 01:21:34 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49FF94D4.3030101@fifthhorseman.net> Date: Mon, 04 May 2009 21:22:28 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: decimal fingerprints [was: Re: Non-SHA-1 fingerprints] References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBCCF34F563DA425E7D624803" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBCCF34F563DA425E7D624803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/04/2009 08:17 PM, David Shaw wrote: >=20 > On May 4, 2009, at 6:04 PM, Daniel A. Nagy wrote: >=20 >> Also, since mobile phones typically have a numeric keypad, it would be= >> nice if >> fingerprints and key IDs were numeric-only. It is an increasingly >> important >> platform for OpenPGP, I believe. >=20 > I think that is a good point and a great idea, but the only reason that= > fingerprints and key IDs are printed in hex now is tradition. There is= > nothing in the standard one way or another about how humans should > consume fingerprints. You could even do it with the current V4 > fingerprints: just as my key fingerprint is > 7D92FD313AB6F3734CC59CA1DB698D7199242560 in hex, it is equally correct > as 716901811312187285520504099705403090347495794016 in decimal. The bi= g > problem I see here is that's it's an awfully long number to type into a= > mobile keypad. How often does anyone type in a fingerprint at all? My impression of the typical workflow is: * read fingerprint from physical media (business card, scrap of paper, e= tc) * search for a key from the public keyservers (usually by User ID). * scan list of results for a key with a matching keyid (truncated fingerprint) * fetch selected key from keyserver * view/double-check fingerprint of fetched key againt physical media In this workflow, the only typing done is to enter the user id to search for (and even that is not always needed on a mobile device, because the person searched for is may already be in the address book for other contacts). if the fingerprint is entered, it's often only the truncated keyid, which is guaranteed to be much smaller than the fpr in any case. Making this change to the fingerprint presentation seems huge: are people expected to change all their business cards, .sigs, web sites, etc. to show both styles of fingerprint? or to completely transition to the new style? in terms of truncated fingerprints (keyids), how are we to distinguish between the ones which currently have only digits 0-9 in hex and decimal-style fingerprints? This seems like a very costly tradeoff for the sake of thumbing in 8 decimal characters instead of 8 hex digits. --dkg --------------enigBCCF34F563DA425E7D624803 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSf+U2czS7ZTSFznpAQpf6g/9Eb8tc0/ShQHeFvOaKhdKSJRLEKGjMLTn XgmTP5SQ8ZclCFs8OQlVVYCHOjYdFxet5joJ6G7e1gQzcGnLpkSjN55/mxrKSRtc f0FlBO9jff/CsBTDRL7YG7RiqR7C89AjitDezHjLT2dCeHRJVxA6uOYLuVrs5b97 pM0u66ujHy4+UtYfqalt760eRUX6q7ZzSAxGdQwjxkn4wZo4cWXWEG2AOWwKrD3V y2MSDQya02w904TaBLrxHYB1eCHod0ZnX+wMpRCbym+tyko9J/hPiKd5SuR9rf8o eRRbsV/thYV34+gV7EABvpO95xuU66ABUGm9GuqKZ5GvA31D3W7cDWnH6CVvUK1D Ct5cASq0EUqZivS+C1CgPY6Q7UYvo9KAIQ0RAWIjUNeMkGA4rmMvv7IYVZAK9YcA YOXX6dkwEKoL3YK26OVztr45Pwra75XXIZA00Su93yrjTml6kA/r7bDgmwbb32G0 vie1IJ+8dPimTIEaXUkqiSoFjGELK1ArBV8T1CPrDIq8LZYVtQGFIsZ5BgDfHdit tnE2d7llw+zS9FQW9jD0AhkRCXlTB8/jvjJee+MrytgMLjeAzKisbEnuNfmcqs/+ Jb0zKa3QMDuBYZ2RgimrkVnkbjF88UjXGCMFKTzaAZAB0YANXksZVLFuQJd4Nuk3 3mfHEc2qYho= =rSZr -----END PGP SIGNATURE----- --------------enigBCCF34F563DA425E7D624803-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n450HDHp089058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 17:17:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n450HD1N089056; Mon, 4 May 2009 17:17:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n450HBwW089041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 17:17:12 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n450H9X0025116; Mon, 4 May 2009 20:17:10 -0400 Cc: IETF OpenPGP Working Group Message-Id: <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com> From: David Shaw To: "Daniel A. Nagy" In-Reply-To: <49FF6677.7070907@epointsystem.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fingerprints) Date: Mon, 4 May 2009 20:17:10 -0400 References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2009, at 6:04 PM, Daniel A. Nagy wrote: > David Shaw wrote: >> >> Now that I think about the variable-hash fingerprint question a >> bit, I'm >> concerned about things like RFC-4398, which uses OpenPGP >> fingerprints in >> DNS. > > For fingerprints, MDC and self-signatures, collision-resistance does > not matter, > only the one-way property. So I think it is totally safe to postpone > discussion > until SHA3 is selected. It's a larger problem than just fingerprints. We also use a fingerprint as a specifier inside the revocation key subpacket, to designate which key can be used to issue revocations on our behalf. The thing is, though, a fingerprint isn't really a very good revocation key specifier: Fingerprints: * Must be human-readable * Needs to be small to be useful * Can collide to some small amount (4880 even documents that they collide in section 12.2) Revocation key specifier: * Does not need to be human-readable * Has much looser size requirements (shouldn't be enormous, but certainly can be bigger than 160 bits without hurting anything) * Should never collide (we don't want the wrong key being able to revoke our key) Perhaps we'd do better by leaving fingerprints alone and instead fixing how we specify revocation keys? We could try to come up with a new non-colliding way to disambiguate keys, but fundamentally, anything that is smaller than the key packet itself can still collide. So instead, why not define a new revocation subpacket that contains the class octet from the old revocation key, and the rest of the subpacket is simply a copy of the public key packet in question? I don't mean the whole transferable public key, of course, just the contents of packet #6. This public key packet doesn't need any self-signatures or anything else like that, as it is implicitly authenticated by the signature that carries the revocation key subpacket. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n450HDi1089057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 17:17:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n450HDcE089055; Mon, 4 May 2009 17:17:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n450HB8s089038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 17:17:12 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n450H9Wx025116; Mon, 4 May 2009 20:17:09 -0400 Cc: IETF OpenPGP Working Group Message-Id: From: David Shaw To: "Daniel A. Nagy" In-Reply-To: <49FF6677.7070907@epointsystem.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Non-SHA-1 fingerprints Date: Mon, 4 May 2009 20:17:09 -0400 References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2009, at 6:04 PM, Daniel A. Nagy wrote: > Also, since mobile phones typically have a numeric keypad, it would > be nice if > fingerprints and key IDs were numeric-only. It is an increasingly > important > platform for OpenPGP, I believe. I think that is a good point and a great idea, but the only reason that fingerprints and key IDs are printed in hex now is tradition. There is nothing in the standard one way or another about how humans should consume fingerprints. You could even do it with the current V4 fingerprints: just as my key fingerprint is 7D92FD313AB6F3734CC59CA1DB698D7199242560 in hex, it is equally correct as 716901811312187285520504099705403090347495794016 in decimal. The big problem I see here is that's it's an awfully long number to type into a mobile keypad. (Well, that, and persuading the various implementations to support the decimal format in addition to the traditional hex). David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44NWxab086472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 16:32:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44NWxei086471; Mon, 4 May 2009 16:32:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44NWw9I086465 for ; Mon, 4 May 2009 16:32:59 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 5E9EA2E659 for ; Mon, 4 May 2009 16:33:51 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30270-05 for ; Mon, 4 May 2009 16:33:46 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 990162E3CA for ; Mon, 4 May 2009 16:33:46 -0700 (PDT) Received: from [10.240.23.244] ([208.54.95.189]) by keys.merrymeet.com (PGP Universal service); Mon, 04 May 2009 16:32:53 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 May 2009 16:32:53 -0700 Cc: IETF OpenPGP Working Group Message-Id: From: Jon Callas To: David Shaw In-Reply-To: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Non-SHA-1 fingerprints Date: Mon, 4 May 2009 16:32:52 -0700 References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the last IETF meeting, Derek discussed new drafts (particularly this one) with Tim Polk, and either Derek can shepherd it, or we can find someone else. I sent Derek a sketch of what I propose. Note that it's pretty much what's been discussed here, but I used a colon (which is what I remember in the original proposal) rather than a dot. > From: "Jon Callas" > Date: April 1, 2009 3:43:08 AM PDT > To: "Derek Atkins" > Cc: "Jon Callas" > Subject: Re: OpenPGP Extensions Doc(s) > > * PGP Signed: 04/01/2009 at 07:37:45 AM, Decrypted > ... > > Here's what I propose: > > We define a new fingerprint. > > Basics > ------ > > The fingerprint is a struct, consisting of: > > Hash Alogrithm Type (1 Octet) > Hash Value (N Octets) > > The hash is computed over the same fields of the key packet, just as > in RFC4880, just with a different hash function than SHA1. > > Truncations > ----------- > > The Hash Value may be of any size equal to or less than the natural > size of the hash function. If it is a truncation, then it is the > high-order bits. Thus, the SHA1 hash "ED15 5BDF CD41 ADFC 00F3 28B6 > 52BF 5A46 BC98 E63D" truncated to 64 bits is "ED15 5BDF CD41 ADFC". > > There are a number of reasons truncating a fingerprint. One is for > ease in transport, display, etc. In the past, we moved from 16-byte > fingerprints to 20-byte fingerprints. While a larger fingerprint may > have increased cryptographic use, human beings still sometimes use > them > > Display > ------- > > The normal display of a fingerprint is: > > : > > White space may be added for readability. > > Example: > > 2:ED15 5BDF CD41 ADFC 00F3 28B6 52BF 5A46 BC98 E63D > > Other formats are possible, but they should remember to show the > algorithm either numberically or symbolically. Note that RFC 4880 > defines ASCII display strings for all algorithms. > > Fingerprint Preference > ----------- ---------- > This is a new preference subpacket that is a single byte of the hash > algorithm preferred fingerprint type. Not only can this be used by > an implementation for display, but an implementation SHOULD use this > algorithm for determining a key id when encrypting to that key. > > If this preference is not present, the implementation SHOULD use old- > style SHA1 fingerprints. > > Key IDs > --- --- > > OpenPGP already has one natural truncation of the fingerprint, the > Key ID. Under this proposal, a Key ID is a 64-bit truncation of the > Hash Value of a fingerprint. An example is given above. > > Note that for SHA1, this means that there are two possible Key IDs, > the old one and a new one. RFC 4880 (and 2440 before it) already > said that an implementation must recognize that there could be > collisions in Key IDs. An implementation SHOULD use the old-style > one unless there is a preference specifying SHA1. > > Other places to look at > ----- ------ -- ---- -- > > We need to look at updating (or handwaving) 5.2.3.15. Revocation Key. > > What do you think? > > Jon > > > -- > Jon Callas > CTO, CSO > PGP Corporation Tel: +1 (650) 319-9016 > 200 Jefferson Drive Fax: +1 (650) 319-9001 > Menlo Park, CA 94025 PGP: ed15 5bdf cd41 adfc 00f3 > USA 28b6 52bf 5a46 bc98 e63d > > > > > * Jon Callas > * 0xBC98E63D(L) > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJ/3slsTedWZOD3gYRAlWTAJ9C2q5AAqUNMLMbsNlz/teDfMaT+ACfYm4U iGyxP9l5DBF+7yAfwR83uu0= =SV8T -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44NQPQJ086141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 16:26:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44NQP5k086140; Mon, 4 May 2009 16:26:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44NQEjb086130 for ; Mon, 4 May 2009 16:26:25 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id CE5732E215 for ; Mon, 4 May 2009 16:27:06 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30270-02 for ; Mon, 4 May 2009 16:27:02 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 3FB282E5B8 for ; Mon, 4 May 2009 16:27:02 -0700 (PDT) Received: from [10.240.23.244] ([208.54.95.189]) by keys.merrymeet.com (PGP Universal service); Mon, 04 May 2009 16:26:09 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 May 2009 16:26:09 -0700 Cc: IETF OpenPGP Working Group Message-Id: <09C603AC-BEE6-43C4-99D0-08B8F4D0BD61@callas.org> From: Jon Callas To: David Shaw In-Reply-To: <06737077-FE52-404C-A540-25076B3A8162@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Changing GPG's default key type Date: Mon, 4 May 2009 16:26:07 -0700 References: <06737077-FE52-404C-A540-25076B3A8162@jabberwocky.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > One issue, of course, is that RSA is not a required key type in > OpenPGP, so there could be some implementation out there that won't > be able to handle it. I'm not terribly concerned about this, as in > practice, the vast majority of code has handled RSA just fine for > the past decade, and if a particular user needs to generate a non- > RSA key, they can still do so. > There are a few other details (RSA signatures are physically larger, > etc), but I believe they are outweighed by the benefit of the larger > key and additional hash flexibility. PGP does precisely this now. The default you'll get when creating a new key is RSA 2048. I'll invoke Jeff Schiller in this as well. The DSA/Elgamal keys are mandatory to implement. Mandatory to implement does not mean mandatory to use. It would be perfectly reasonable to make an RSA-only system that merely didn't hork up a hairball when it found a DSA key. Many X.509 systems are like this too -- DSA is the mandatory-to- implement, but it's not clear that anyone has ever created a DSA certificate outside of interop testing. I'm sure someone can find some example that proves me literally wrong on that, but figuratively right. These days, I see the effective -- ummm, I'm looking for the right word, I don't want to say "deprecate" -- minimization of integer discrete log. The world is pretty much integer RSA, and moving to elliptic curve discrete log. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJ/3mRsTedWZOD3gYRAvnSAJ930wrrwBfdtMQR7u45vOXhP1nCqQCcCUSb mmQtr8tYoSe5XMK6ya3Jg5Q= =JpoU -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44MJKuH082315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 15:19:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44MJK3l082314; Mon, 4 May 2009 15:19:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from netscalibur-outbound-smtp03.uk.clara.net (netscalibur-outbound-smtp03.uk.clara.net [213.253.59.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44MJ97m082294 for ; Mon, 4 May 2009 15:19:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from skaro.afraid.org ([212.169.1.61]:41870) by relay03.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.43]:1325) with esmtp id 1M16V9-0003rE-CR (Exim 4.69) (return-path ); Mon, 04 May 2009 23:19:07 +0100 Received: from ip80-101-225-144.hotspotsvankpn.com (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 52A5E5D65; Mon, 4 May 2009 23:19:04 +0100 (GMT/BST) Message-ID: <49FF69D9.7070206@systemics.com> Date: Tue, 05 May 2009 00:19:05 +0200 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: David Shaw Cc: IETF OpenPGP Working Group Subject: Re: Non-SHA-1 fingerprints References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> In-Reply-To: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 4/5/09 23:35, David Shaw wrote: > This does, of course, presume that all of our hashes for OpenPGP in the > future will generate an even number of bytes. I like the idea. But, I'm the one who favours aphorisms such as "there is only one mode, and it is secure." Or, perhaps, "There is one cipher suite, and it is numbered Number 1." So I would be looking for SHA3 as the one and only thing that ever hashes the publics, and bugger the rest. Algorithm agility is for the birds. We would just need to agree how many even bytes to allocate to the SHA3 for the next 4 decades. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44M9bBd081710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 15:09:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44M9bGE081709; Mon, 4 May 2009 15:09:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44M9ZFJ081702 for ; Mon, 4 May 2009 15:09:36 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 40FCB31A58B for ; Tue, 5 May 2009 00:09:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 1A884598099 for ; Tue, 5 May 2009 00:09:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NW5dxk15LoHW for ; Tue, 5 May 2009 00:09:34 +0200 (CEST) Received: from [10.0.0.232] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id D15D7598091 for ; Tue, 5 May 2009 00:09:34 +0200 (CEST) Message-ID: <49FF679E.1090400@epointsystem.org> Date: Tue, 05 May 2009 00:09:34 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: New results against SHA-1 References: <9D828E6C-482D-4AC1-B56F-F3DF3D02E4C7@jabberwocky.com> <49FF0A74.5030805@fifthhorseman.net> <87iqkgbwff.fsf@wheatstone.g10code.de> <49FF325A.80106@fifthhorseman.net> In-Reply-To: <49FF325A.80106@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig61BC0E22A9B40C8F1917A17F" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig61BC0E22A9B40C8F1917A17F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Ugh. that's horrifically long either way. Is a base64 encoding worth > considering? it would shave off a third of the length, but it seems > like it would introduce significant ambiguity (0 vs O, A vs a, etc) I would go the other way. Since collision-resistance is not an issue with= fingerprints, 128 bits are perfectly adequate for 2048-bit keys (i.e. bre= aking the key and making a new key matching the fingerprint require about the s= ame amount of work). Also, keeping mobile phones in mind, I would suggest usi= ng 40 decimal digits. This way, the total length of fingerprints remain the sam= e (40 characters), but typing them in on a decimal keypad would be much faster = than currently. --=20 Daniel --------------enig61BC0E22A9B40C8F1917A17F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkn/Z54ACgkQoeH/BzqmYjhxbgCgjDKZk2nfRWSZojAa9qklaeZR rQwAn2XGQCI0Q8Z2ckSWMHITtpd7mU4s =2qFS -----END PGP SIGNATURE----- --------------enig61BC0E22A9B40C8F1917A17F-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44M4rdl081493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 15:04:53 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44M4rhT081492; Mon, 4 May 2009 15:04:53 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44M4fpv081481 for ; Mon, 4 May 2009 15:04:52 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 8F77C31A571; Tue, 5 May 2009 00:04:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 112B8598099; Tue, 5 May 2009 00:04:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xcNlf78UM7xl; Tue, 5 May 2009 00:04:39 +0200 (CEST) Received: from [10.0.0.232] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id C9A52598091; Tue, 5 May 2009 00:04:39 +0200 (CEST) Message-ID: <49FF6677.7070907@epointsystem.org> Date: Tue, 05 May 2009 00:04:39 +0200 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: David Shaw CC: IETF OpenPGP Working Group Subject: Re: Non-SHA-1 fingerprints References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> In-Reply-To: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3A44C71DF68C61ECC525EF57" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A44C71DF68C61ECC525EF57 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Shaw wrote: >=20 > Now that I think about the variable-hash fingerprint question a bit, I'= m > concerned about things like RFC-4398, which uses OpenPGP fingerprints i= n > DNS.=20 For fingerprints, MDC and self-signatures, collision-resistance does not = matter, only the one-way property. So I think it is totally safe to postpone disc= ussion until SHA3 is selected. Reviewing the fingerprint is a MAJOR issue, as (parts of) fingerprints ar= e used as lookup keys in the PKS database. Here are some points: I believe that a fingerprint that is longer than 160 bits is pointless; e= ven 160 bits is an overkill causing inconvenience with no tangible benefit in ter= ms of security over a 128 bit fingerprint. What does cause some problems, is the fact that the creation date (32 bit= s) is included in the fingerprint. It makes sevaral attacks substantially easie= r than if the fingerprint was calculated only over the key material and key attr= ibutes (such as key type). Basically, it should be impossible for the same key t= o have different fingerprints. Also, since mobile phones typically have a numeric keypad, it would be ni= ce if fingerprints and key IDs were numeric-only. It is an increasingly importa= nt platform for OpenPGP, I believe. --=20 Daniel --------------enig3A44C71DF68C61ECC525EF57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkn/ZncACgkQoeH/BzqmYjhfeACfRnMUEXiw7+Y1Yvnp8TYGchbh 2U8AoKbcP+V3g8YXf+hJlsWbgdJyQe9z =ce8+ -----END PGP SIGNATURE----- --------------enig3A44C71DF68C61ECC525EF57-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44LpwX1080695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 14:51:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44Lpw7L080694; Mon, 4 May 2009 14:51:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44LpuKV080687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 14:51:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (system178.22.202.65 [65.202.22.178] (may be forged)) (authenticated bits=0) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n44Lpt82023932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 May 2009 17:51:56 -0400 Message-Id: <0F0DEA3C-A1B9-4F24-8F1E-9B8649F2464C@jabberwocky.com> From: David Shaw To: IETF OpenPGP Working Group In-Reply-To: <49FF325A.80106@fifthhorseman.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Subject: Re: New results against SHA-1 Date: Mon, 4 May 2009 17:51:55 -0400 References: <9D828E6C-482D-4AC1-B56F-F3DF3D02E4C7@jabberwocky.com> <49FF0A74.5030805@fifthhorseman.net> <87iqkgbwff.fsf@wheatstone.g10code.de> <49FF325A.80106@fifthhorseman.net> X-Mailer: Apple Mail (2.930.4) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2009, at 2:22 PM, Daniel Kahn Gillmor wrote: > On 05/04/2009 01:38 PM, Werner Koch wrote: >> Using a number (2) and, say, a dot as a prefix would be a better >> choice. >> We use algorithnm numbers anyway and OpenPGP users are used tp >> spell a >> large row of hex digits; we would only confuse them with an S and >> an H.. > > ok, that works for me. would the prefix be in hex or decimal? for > example, would an SHA512 fingerprint look like > a. > 3dd7a2cb8f9e51f2fc096e7022a8192099aa89e10c699e46223851cc36f406b1beb734d5a7da0d8ebc08cc37e30088300c7a9ae81ba7ab758047a89cfa191aff > > or > > 10.3dd7a2cb8f9e51f2fc096e7022a8192099aa89e10c699e46223851cc36f406b1beb734d5a7da0d8ebc08cc37e30088300c7a9ae81ba7ab758047a89cfa191aff > > Ugh. that's horrifically long either way. Is a base64 encoding worth > considering? it would shave off a third of the length, but it seems > like it would introduce significant ambiguity (0 vs O, A vs a, etc) I'm sure there is a study somewhere that says just how long of a string a human being can handle without getting lost, but even without such a study I can say that 512 bits is just too long for usability. If you think about it, the whole point of fingerprints is that they're a short way to refer to a key. If we make them too long, we're hurting the very thing that fingerprints were created for. "3dd7a2cb8f9e51f2fc096e7022a8192099aa89e10c699e46223851cc36f406b1beb734d5a7da0d8ebc08cc37e30088300c7a9ae81ba7ab758047a89cfa191aff " is not exactly the kind of thing someone could print on a business card or read to a corespondent over the phone. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44LZDTV079793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 14:35:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44LZDJW079792; Mon, 4 May 2009 14:35:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44LZ2Ja079782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 14:35:13 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (system178.22.202.65 [65.202.22.178] (may be forged)) (authenticated bits=0) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n44LZ1Ho023777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for

Hello!

Shipped Privately And Discreetly To Your Door!

Hello!

Shipped Privately And Discreetly To Your Door!

Hello!

Shipped Privately And Discreetly To Your Door!