Subject: Re: Your subscribe #624277

From: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF03D821D9477C6E3CE5003E0"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFF160891008B155E9CB1BCC3"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
Mail-Followup-To: Lionel Elie Mamane , Ian G , IETF OpenPGP Working Group
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
Mail-Followup-To: Lionel Elie Mamane , Ian G , IETF OpenPGP Working Group
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBE9288F01ECA740305A0E4C1"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3E288F6834146C1C811D07D6"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
Date: Fri, 08 May 2009 22:47:29 +0200
In-Reply-To: <[email-masked]> (Jon Callas's message of "Tue, 5 May 2009 10:58:14 -0700")
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig44DC6E51A3726AD501084468"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig40F5A262D60EEB9E17B2A2D8"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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 <[email-masked]> for [email-masked]; 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 <[email-masked]> for [email-masked]; 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: <[email-masked]> <[email-masked]>
In-reply-to:
Content-type: multipart/signed; boundary=nextPart51737562.EtnubJnk9m; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit
Message-id: <[email-masked]>
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
From: Jon Callas
To: Daniel Franke
In-Reply-To: <[email-masked]>
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: <[email-masked]> <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: [email-masked] (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: <[email-masked]>
X-Hashcash: 1:26:090505:[email-masked]::FWfm+2gA8G6xCEMY:000000000000000000000000000000000000000003UWa
X-Hashcash: 1:26:090505:[email-masked]::h6ykG/NGawgQKom8:000BNMG
Date: Tue, 05 May 2009 12:18:41 -0700
In-Reply-To: <[email-masked]> (sfid-20090505_110311_348312_3F415D8B) (Jon Callas's message of "Tue, 5 May 2009 10:58:14 -0700")
Message-ID: <[email-masked]>
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: [email-masked]
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 [email-masked] 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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
Received: by finney.org (Postfix, from userid 500) id 83D7814F6E1; Tue, 5 May 2009 08:03:00 -0700 (PDT)
To: [email-masked]
Subject: Re: Non-SHA-1 fingerprints
Message-Id: <[email-masked]>
Date: Tue, 5 May 2009 08:03:00 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig171F5511815A85E73F57BC1D"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]> <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 05 May 2009 13:28:14 +0200
In-Reply-To: <[email-masked]> (Daniel A. Nagy's message of "Tue, 05 May 2009 08:30:07 +0200")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Tue, 5 May 2009 08:30, [email-masked] 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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 05 May 2009 09:09:01 +0200
In-Reply-To: <[email-masked]> (Daniel Kahn Gillmor's message of "Mon, 04 May 2009 14:22:18 -0400")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 4 May 2009 20:22, [email-masked] 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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 05 May 2009 08:59:33 +0200
In-Reply-To: <[email-masked]> (Daniel Kahn Gillmor's message of "Mon, 04 May 2009 22:49:18 -0400")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Tue, 5 May 2009 04:49, [email-masked] 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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigADA531ADE781892CA88A4D27"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7486F63840E3487114A61F7A"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC704609DD70F977B4CBDADD5"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF756CAA244F068AD36E04778"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: [email-masked], [email-masked]
Subject: Re: Changing GPG's default key type
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Tue, 05 May 2009 15:02:36 +1200
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig107BF823AF3E617747B108F1"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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 [email-masked]; Tue, 05 May 2009 14:46:29 +1200
From: Peter Gutmann
To: [email-masked]
Subject: Re: New results against SHA-1
In-Reply-To: <[email-masked]>
Message-Id:
Date: Tue, 05 May 2009 14:46:29 +1200
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE9C3B898F6A8B9A72D08A57A"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
From: David Shaw
To: "Daniel A. Nagy"
In-Reply-To: <[email-masked]>
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: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
From: Jon Callas
To: David Shaw
In-Reply-To: <[email-masked]>
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: <[email-masked]>
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: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig61BC0E22A9B40C8F1917A17F"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
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: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3A44C71DF68C61ECC525EF57"
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
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: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
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 [email-masked])
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 [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 [email-masked])
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 ; Mon, 4 May 2009 17:35:01 -0400
Message-Id: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group
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: Non-SHA-1 fingerprints
Date: Mon, 4 May 2009 17:35:01 -0400
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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. There is a fingerprint field there, and it is
variable length, but it has no concept of hash algorithm. We'd have
to define some standard way to write out a fingerprint in binary with
the hash field incorporated.

So given that, I am wondering why we need a delimiter between the hash
specifier and the fingerprint data for the human-readable version at
all? A written fingerprint is expected to be readable, but not
interpretable by a human being anyway, and software doesn't care about
the delimiter one way or another.

So rather than 01.23456789ABCDEF.... or MD5-23456789ABCDEF... why not
just 0123456789ABCDEF... ?

We already have a concept of variable length fingerprints (V3 = 16
bytes, and V4 = 20 bytes), and this fits reasonably well alongside
those two. The rule would be 16 bytes means it's V3, 20 bytes means
it's V4, and an odd number of bytes means it's this new format. If
you see an odd number of bytes, you pull off the leftmost byte, and
that's the algorithm number. The rest of the bytes are the hash
value. We can trivially transform a V4 fingerprint into this new
format by sticking the value 2 in front of it.

This does, of course, presume that all of our hashes for OpenPGP in
the future will generate an even number of bytes.

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 n44JjrTX072189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 12:45:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44JjrnU072187; Mon, 4 May 2009 12:45:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44JjpXp072177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 12:45:52 -0700 (MST) (envelope-from [email-masked])
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 n44Jjok3022882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 May 2009 15:45:51 -0400
Message-Id: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
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 15:45:50 -0400
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On May 4, 2009, at 3:24 PM, Daniel Kahn Gillmor wrote:

> On 05/04/2009 02:57 PM, David Shaw wrote:
>> we would have to play length checking games
>> to guess if they meant hash 4 or 40.
>
> We're still going to have to do a little bit of length-checking games,
> to distinguish between traditional SHA1 fingerprints and an
> accidentally-truncated version of the newer (and presumably longer)
> fingerprints.

We can use the presence of the delimiter dot to tell the difference.

If they've lost the dot, then, well, absent some special knowledge, we
can't really tell the difference between a old-style fingerprint and a
new-style fingerprint that is both accidentally truncated and missing
its delimiter dot. I wouldn't even try.

Note that the current OpenPGP does not attempt to tell the difference
between a V3 fingerprint (32 printed digits) and a V4 fingerprint that
just happened to lose 8 characters in a cut and paste error
somewhere. That's the job of the client (if it chooses to take it on
at all) more so than the job of the protocol.

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 n44JPdue070689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 12:25:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44JPdQF070688; Mon, 4 May 2009 12:25:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44JPRRM070676 for ; Mon, 4 May 2009 12:25:38 -0700 (MST) (envelope-from [email-masked])
Received: by bwz22 with SMTP id 22so4021195bwz.10 for ; Mon, 04 May 2009 12:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CjQUsywfVRGnWO7w3luIJPeKdKuyqA3ISTRnQm/0um8=; b=C18BoKzQEZRk26m4vyNrFiNgw0YwGHtL7Deuqx7i3UZ7sokeDa2AfuHsjwtyV+UWHP i11XLWUbvL0WMVXaXMok8JZrfu38+nl7jfYbXsGWk1F2YGQv6MikLu28FG/yQwixkx0c kh7+3nP97Yk18qQw8LxDIYnm7+DAWtTY2ahsA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YCzt9UymiDnKbaU4GvKhxv0QTgy3Y0CCYPm1aLNQ1k6c50AX0X4m8QSFvFuZEkLMwA Jbomxn83XPiADUo9cPtu7KZnmH1bFnO+QJznfBmqnCt8yIfm0cJZkKlUD2T4AD7W4Ijl pUDSede9nusTDdeulqMqFly6T13/bP2QTRqII=
MIME-Version: 1.0
Received: by 10.204.69.66 with SMTP id y2mr6072460bki.49.1241465126246; Mon, 04 May 2009 12:25:26 -0700 (PDT)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 4 May 2009 20:25:26 +0100
Message-ID: <[email-masked]>
Subject: Re: New results against SHA-1
From: David Crick
To: IETF OpenPGP Working Group
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, May 4, 2009 at 8:15 PM, Daniel Kahn Gillmor
wrote:
> On 05/04/2009 02:39 PM, [email-masked] wrote:
>> MDC's ?
>>
>> currently SHA-1
>> rfc-4880 p. 49 ff
>
> Ah, right. =A0Jon Callas' remarks about the MDC from back in January migh=
t
> be relevant:
>
> =A0http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024967.html
>
> I think his point stands that the MDC only cares about the one-wayness
> of the digest used in MDC -- there is no reliance on a
> collision-resistance property. =A0So i'm not sure that this needs to
> change in a new draft, particularly if it could make the discussion more
> contentious.
>
> What do other folks think?

I think we need to address it; we may as well, plus also
during the IETF review of the draft of what would become
4880, we have to CONVINCE IETF that it was "OK" to use
SHA-1 here (when there were already concerns about it).

"SHA-1 baad, mm'ok?" :)

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 n44JNGgX070552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 12:23:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44JNGES070551; Mon, 4 May 2009 12:23:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n44JNFrb070537 for ; Mon, 4 May 2009 12:23:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 19140 invoked from network); 4 May 2009 19:23:14 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 4 May 2009 19:23:14 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 15:24:13 -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: New results against SHA-1
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3377F6EA6DEFE8F1B189E8C5"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3377F6EA6DEFE8F1B189E8C5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 05/04/2009 02:57 PM, David Shaw wrote:
> we would have to play length checking games
> to guess if they meant hash 4 or 40.

We're still going to have to do a little bit of length-checking games,
to distinguish between traditional SHA1 fingerprints and an
accidentally-truncated version of the newer (and presumably longer)
fingerprints.

One of the reasons that i initially proposed prefixes like SHA256- is
because they are so unambiguously *unlike* the traditional fingerprints
that it is clear what to expect next.

--dkg

--------------enig3377F6EA6DEFE8F1B189E8C5
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

iQIVAwUBSf9A3szS7ZTSFznpAQqrTQ/5ASHx4M4jOukvhduteqhbHSYdrs7mxK5e
FXwsiiFS6EZzng3hSfair5T6EHKaBHQkfCEnlI17fPluXM5jZgMT/owbmUlL3orU
nAuff4/lKvnf/esrKfMRhb9igg8UHZXweW7lqT8hxL+GHIWF+NnqIlMjA91BpufL
rczzbumid4Is3QTeFDceG/xJFZY9/Tx6jHw8H+pgpbTte2PShptti+e8m5SToCRK
fQIhL404kv/XJFitIzw7OqoYQoigrh8e3nKxxjx2GjDnIClRNLKkB0tEH1h1CpP+
iRTJs/XrCWZosZbjkBJ8p0L/v6Qu+LpblZZfqmqfJGN281+cy4zm5qCpFFhuRs6m
FI5ESmBPZ1+bteLij5v0zqYxu+qR0Fq5OjrHArvkloy4sP1oWjoNDuhDTFj2y8Vy
yVACcYKKJ5+QQJZjaBvYyuDMigps5R2zCaPDEdQsQnPf70TgJnqVaAN85jpD2Agk
J7+LgwuL5YJ9IXyK0OBXqdeQqvhLIQyLl8UP5HbcSio6NGAV/qnxTkzgoi456j2k
eIcP+f7jXXr6khyysOlTklhKaIZMHJJicZ9bKLVihr4GiaoU6MzUOU1MPqDEAIGm
86ABiBomr1ZuTmV6zn07mhG9tl8xJ7F5pHHkxQVfaGK90Wx+PO4OIJgMdHezOihd
/dxudUVwf7Y=
=I4ZX
-----END PGP SIGNATURE-----

--------------enig3377F6EA6DEFE8F1B189E8C5--

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 n44JERnC069907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 12:14:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44JERWZ069904; Mon, 4 May 2009 12:14:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n44JEGRt069840 for ; Mon, 4 May 2009 12:14:26 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 14369 invoked from network); 4 May 2009 19:14:15 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 4 May 2009 19:14:15 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 15:15:14 -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: New results against SHA-1
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig14CC89960466A28BEAC9A5A5"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig14CC89960466A28BEAC9A5A5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 05/04/2009 02:39 PM, [email-masked] wrote:
> MDC's ?
>=20
> currently SHA-1
> rfc-4880 p. 49 ff

Ah, right. Jon Callas' remarks about the MDC from back in January might
be relevant:

http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024967.html

I think his point stands that the MDC only cares about the one-wayness
of the digest used in MDC -- there is no reliance on a
collision-resistance property. So i'm not sure that this needs to
change in a new draft, particularly if it could make the discussion more
contentious.

What do other folks think?

--dkg

--------------enig14CC89960466A28BEAC9A5A5
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

iQIVAwUBSf8+wszS7ZTSFznpAQrOGw//djHRreV/gQYDsEsCgxVLBf7F7g3jAQwY
NmttihGJAw+egC6u8TcwMGb4nT+B/YKXMc5WiyQmgH8ekeiKll74g00ZOm1fHdEq
0DYZFRQLmhipzTuok0gCQa+FOtcippa6HAd23+v4L7KvDmUstLzszSc7eTUHpLX7
HhcelVdb9G9eRMDaKQFX+xVH2sYsVtln5d2KbiBY9NJKJOywaoyt3WghhvVyR4cU
xj4rawzDriCU35peULoFcuAObh2oDlK6SPrxXAGAG3s8S9+Hv3edT4UoKcOJVtsS
4GEBPbVnLQvDbjFk2hLKZ64GMfEwi0eiv/w82seuEuVPH5Ml23Lr2itD7mPzE8bN
6oedDxnzdoqm5KMl+SRrd8R/mTR+goSM6Pj8llx+mAuacvtimmtzPC61zYDB9Pfx
MALmTGeNEdLS+1g+3GQ5W7HiptiNH4pyK2xLL58/jXgNfgAEISLGUpNl0skYJg/D
ryX0Do3jn/5ceZSGQGsVVZjGeeOrk5euyOye5DmARWiy4QrkzS4pykTp1tRskEUo
air3YviYt+iNgze+h94icZljG4vusPvjVlhXIXPNGQyB4L3qZ4NWhsbGIb181H+h
cMkP+4Fb+GxRgJehZRjg9Gsm0e51gboB8W2PDYrpICrbKYXjvy3ZJnt/gt2BJbcI
wAxwYPonsDs=
=afkV
-----END PGP SIGNATURE-----

--------------enig14CC89960466A28BEAC9A5A5--

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 n44Iw59f068538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 11:58:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44Iw5Pd068537; Mon, 4 May 2009 11:58:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44Iw4qi068531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 11:58:05 -0700 (MST) (envelope-from [email-masked])
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 n44IvLtF022390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 May 2009 14:57:21 -0400
Cc: IETF OpenPGP Working Group
Message-Id: <[email-masked]>
From: David Shaw
To: Werner Koch
In-Reply-To: <[email-masked]>
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 14:57:21 -0400
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On May 4, 2009, at 1:38 PM, Werner Koch wrote:

>
> On Mon, 4 May 2009 17:32, [email-masked] said:
>> current fingerprint would be re-written as:
>>
>> SHA1-0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>
> 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..

I like the dot, but I'd like to see the hash number in two-digit hex.
The reason is that I strongly suspect that when read out over the
phone, or written down, or transmitted in pretty much any means other
than strict cut-and-paste, the dot (or any other delimiter) will be
lost in translation. Thus, "40.ABCDEF0123456....." will become
"40ABCDEF0123456....." and we would have to play length checking games
to guess if they meant hash 4 or 40.

With 2-digit hex, "4" would be written as "04", removing any doubt.

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 n44Ie2G2067128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 11:40:02 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44Ie2gs067127; Mon, 4 May 2009 11:40:02 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp12.hushmail.com (smtp12.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44IdolO067098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 May 2009 11:40:01 -0700 (MST) (envelope-from [email-masked])
Received: from smtp12.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp12.hushmail.com (Postfix) with SMTP id 6F9EA70271 for ; Mon, 4 May 2009 18:39:49 +0000 (UTC)
Received: from smtp.hushmail.com (mailserver8.hushmail.com [65.39.178.61]) by smtp12.hushmail.com (Postfix) with ESMTP for ; Mon, 4 May 2009 18:39:48 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id AA2D51A003A; Mon, 4 May 2009 18:39:48 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 04 May 2009 14:39:48 -0400
To: "IETF OpenPGP Working Group"
Subject: Re: New results against SHA-1
From: [email-masked]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 04 May 2009 11:32:04 -0400 Daniel Kahn Gillmor
wrote:
>On 04/30/2009 06:39 PM, David Shaw wrote:
>>
>>
>http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.

>pdf
>>
>> There is not much hard information yet, but the two big quotes
>are
>> "SHA-1 collisions now 2^52" and "Practical collisions are within
>> resources of a well funded organisation."

>What else should be addressed?

MDC's ?

currently SHA-1
rfc-4880 p. 49 ff

vedaal

any ads or links below this message are added by hushmail without
my endorsement or awareness of the nature of the link

--
Click to learn about options trading and get the latest information.
http://tagline.hushmail.com/fc/BLSrjkqecvgn6JU6GKTTYn4JLCimaHzrO00szZPMXyt3Ax5yZ2fL1OvWzD6/

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 n44ILPBN066013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 11:21:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44ILPH9066012; Mon, 4 May 2009 11:21:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44ILOHs066006 for ; Mon, 4 May 2009 11:21:25 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 55092 invoked from network); 4 May 2009 18:21:23 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay00.pair.com with SMTP; 4 May 2009 18:21:23 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 14:22: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: New results against SHA-1
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9CD82D7FEB196C5B478EC8A3"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9CD82D7FEB196C5B478EC8A3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=
=2E
> 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.=
=2E

ok, that works for me. would the prefix be in hex or decimal? for
example, would an SHA512 fingerprint look like
a.3dd7a2cb8f9e51f2fc096e7022a8192099aa89e10c699e46223851cc36f406b1beb734=
d5a7da0d8ebc08cc37e30088300c7a9ae81ba7ab758047a89cfa191aff

or

10.3dd7a2cb8f9e51f2fc096e7022a8192099aa89e10c699e46223851cc36f406b1beb734=
d5a7da0d8ebc08cc37e30088300c7a9ae81ba7ab758047a89cfa191aff

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)

>> e) allow injection of arbitrary key material at the head of signature=
s
>> to allow signers to to avoid a chosen-prefix attack? This would make =
it
>> significantly more difficult to predict the hash that someone will sig=
n,
>=20
> and gives more bandwidth for a subliminal channel...

True, but some room for the subliminal channel already exists (e.g.
notations can be injected in the signed material). This would simply
allow signers to better control what they actually sign, rather than
being compelled into signing a given text. Daniel Franke's recent
message on gnupg-devel about this is interesting:

http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024967.html

Another approach would be to formally prefer digest algorithms that do
not exhibit the same single-pass behavior of SHA-1 -- is that feasible?

>> f) explicit introduction of new hashes/ciphers/asymmetric algorithms?=

>=20
> We should defer such a discussion until there are semi final results
> from the SHA-3 contest.

SHA-3 finalizes in the end of 2012, though first-round candidates have
already been selected. Third quarter of 2010 should have finalists
selected:

http://csrc.nist.gov/groups/ST/hash/timeline.html

Which phase of the timeline would be sufficient for you?

> Right, we should re-establish the WG to no rely on I-Ds by individuals.=

So what's the process to do this?

--dkg

--------------enig9CD82D7FEB196C5B478EC8A3
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

iQIVAwUBSf8yX8zS7ZTSFznpAQpoPw//eeXQ64tF5ABLRWImiVF3GdCZluqcDz3P
ZTY+h8YPigxxmnNSTvDxvBSB0w3uu/PrI/O3h0v48HRE5Q2ipbdjdcEbfLt4c/+b
zrvNl/4OccmwRL49qJnievsMBZQSvLd90xROEdB25jOU7q4eoGmFM9Fboz81YWOR
CiGSlLnz/iEhqP8v2sCaP9ZFCSNM925tsmOtNdYAPwBLQ1iSUWCRJ4C2l2mOIK7k
mZWie3rSxrhHjc+Go6K05c11ZSo2ifjUgwax4RdCNrYD+K9cAh7f/vkrMdZz8Prw
nhnnhF/2BlxptBduGR5th126QYthaxG+QRBsDOQaXnq+TOKT7fX7Ajx0308FFqc9
eL236qiqQWte0xWm3XrYZCYRNcRXckdVcBh60IPwzWb6Sqe38eNCG9Etu39vAhky
IaB7KHRES3REBIY6ZxrFJi2GyIsC+IMXEYQgtsHthRqw3q51YZzf9HQOUPz/oRcq
1wUrmVnp2GWvvUwFvVZFWaxS9cXaAIr56d1bHGiY0KtSRzR3uAB/FxaJWnk3unRd
xaTSn2UJC0kuBaOYJPoRPYY5NTKfbIn+V1vxS7jlrfGXqCDGl3MymHa3LJ4Escbj
FIRUlwvVUgzPsV3g/1uiCOb1j4+wnDmrlaoUXQ316qf6x7gUDwP0TL8u4NVrF8DL
9Ru4HW5fDSQ=
=/xKh
-----END PGP SIGNATURE-----

--------------enig9CD82D7FEB196C5B478EC8A3--

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 n44I7su7064123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 11:07:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44I7s0T064122; Mon, 4 May 2009 11:07:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44I7gVd064103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 11:07:54 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-93-104-127-5.dynamic.mnet-online.de [93.104.127.5]) by mailgw02.dd24.net (Postfix) with ESMTPA id 0AB6F35546C for ; Mon, 4 May 2009 18:07:42 +0000 (GMT)
Subject: Re: Changing GPG's default key type
From: Christoph Anton Mitterer
To: IETF OpenPGP Working Group
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-TqwuP8rGE/wYOL6Ec1bJ"
Date: Mon, 04 May 2009 20:07:41 +0200
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-TqwuP8rGE/wYOL6Ec1bJ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2009-05-04 at 14:00 -0400, David Shaw wrote:
> Concerns about compatibility, mainly. There is a much larger =20
> installed base of clients that understand SHA-1 than that understand =20
> (say) SHA-256. SHA-256 has only been understood in a non-development =20
> version of GPG since 2004. If I recall properly, PGP added it more or =20
> less around the same time. That's not that long ago, and I frequently =20
> see people asking for support for some version of GPG or PGP that =20
> predates SHA-256.
At least we've seen from the recent SHA1-related events,... that this
point is comming closer ;)

> None of this means that we wouldn't change the default signing hash at =20
> some point later. It's just not something we're currently planning on =20
> for today.
Of course :)

Chris.

--=-TqwuP8rGE/wYOL6Ec1bJ
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDUwNDE4MDc0MVowIwYJKoZIhvcNAQkEMRYEFNGCmj8sZK0DhoZ3DPl3EpWmN2RIMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AD4lPWSZmUQJ4p2ufa5TBmwGw32UBUdBM8XP9AGBHZqYzvS/DBEbzJP/spr1d7YIB/Yt28LXnKFN
TRaaDvhTj0QYnmZiUI0/WBBh0M9H8FROM61+vct05ahJ13vPOncwk9NMcVavfkfotC3rdcQK4PLB
04aWzCluGJkI/MALE/v+4acSroorOgvBpV5XKvBSLmFnH6DmkZD4i6mDr9xqYZKSm+qZB+qyV8d1
YTj8U5GtyYqRMPm5V0wnnwuzoahzoS0VvO3rkQ9ZZM9cwHb7lcBNunYUXFybspiiPWTXCdUcOg7f
sbyeMAMYiGyk58vIo3uJFvUVlYoqM+V6y1KSFt0AAAAAAAA=

--=-TqwuP8rGE/wYOL6Ec1bJ--

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 n44I0PDk063585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 11:00:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44I0PWU063584; Mon, 4 May 2009 11:00:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44I0D5t063572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 11:00:24 -0700 (MST) (envelope-from [email-masked])
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 n44I0CJk021847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 May 2009 14:00:13 -0400
Cc: IETF OpenPGP Working Group
Message-Id:
From: David Shaw
To: Christoph Anton Mitterer
In-Reply-To: <[email-masked]>
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: Changing GPG's default key type
Date: Mon, 4 May 2009 14:00:12 -0400
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On May 4, 2009, at 1:28 PM, Christoph Anton Mitterer wrote:

> On Mon, 2009-05-04 at 10:40 -0400, David Shaw wrote:
>> We are currently thinking about changing the default
>> primary to a 2048-bit RSA key.
> Nice :-)
>
>> We are not proposing changing our default
>> signing hash, which will remain SHA-1.
> Uhm.. why not?

Concerns about compatibility, mainly. There is a much larger
installed base of clients that understand SHA-1 than that understand
(say) SHA-256. SHA-256 has only been understood in a non-development
version of GPG since 2004. If I recall properly, PGP added it more or
less around the same time. That's not that long ago, and I frequently
see people asking for support for some version of GPG or PGP that
predates SHA-256.

Mind you, we're not stopping people from choosing to use SHA-256 or
whatever they like, and with a RSA key, they are of course free to
choose anything. SHA-1 is just a default. One way to look at the RSA
change, in fact, is to enable users to make their own hash choice,
which they didn't really have with the previous default of a 1024-bit
DSA key (so locked at 160 bits).

None of this means that we wouldn't change the default signing hash at
some point later. It's just not something we're currently planning on
for today.

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 n44Hko3r062224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 10:46:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44HkoEn062223; Mon, 4 May 2009 10:46:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44HkmMD062215 for ; Mon, 4 May 2009 10:46:49 -0700 (MST) (envelope-from [email-masked])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.63 #1 (Debian)) id 1M12Fa-0002cM-Hs for ; Mon, 04 May 2009 19:46:46 +0200
Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1M127Y-0007gx-OA for ; Mon, 04 May 2009 19:38:28 +0200
From: Werner Koch
To: IETF OpenPGP Working Group
Subject: Re: New results against SHA-1
References: <[email-masked]> <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 04 May 2009 19:38:28 +0200
In-Reply-To: <[email-masked]> (Daniel Kahn Gillmor's message of "Mon, 04 May 2009 11:32:04 -0400")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 4 May 2009 17:32, [email-masked] said:
> current fingerprint would be re-written as:
>
> SHA1-0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

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..

> e) allow injection of arbitrary key material at the head of signatures
> to allow signers to to avoid a chosen-prefix attack? This would make it
> significantly more difficult to predict the hash that someone will sign,

and gives more bandwidth for a subliminal channel...

> f) explicit introduction of new hashes/ciphers/asymmetric algorithms?

We should defer such a discussion until there are semi final results
from the SHA-3 contest.

> I've probably missed something. What else should be addressed? What
> steps are necessary to get the WG back in order again? Or is that not

Right, we should re-establish the WG to no rely on I-Ds by individuals.

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 n44HSvOG061013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 10:28:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44HSv4D061012; Mon, 4 May 2009 10:28:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44HSjCk060991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 10:28:56 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-93-104-127-5.dynamic.mnet-online.de [93.104.127.5]) by mailgw01.dd24.net (Postfix) with ESMTPA id 0FE127CC66D; Mon, 4 May 2009 17:28:44 +0000 (GMT)
Subject: Re: Changing GPG's default key type
From: Christoph Anton Mitterer
To: David Shaw
Cc: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-H+nUPs1cUv+b2JQsJxx7"
Date: Mon, 04 May 2009 19:28:43 +0200
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-H+nUPs1cUv+b2JQsJxx7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2009-05-04 at 10:40 -0400, David Shaw wrote:
> We are currently thinking about changing the default =20
> primary to a 2048-bit RSA key.
Nice :-)

> We are not proposing changing our default =20
> signing hash, which will remain SHA-1.
Uhm.. why not?

Chris.

--=-H+nUPs1cUv+b2JQsJxx7
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDUwNDE3Mjg0M1owIwYJKoZIhvcNAQkEMRYEFGQ1X5fulypDcmv4l7L+HM0g9wGbMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
ABuKf/d/NXUCyjnLKEy9V6BqPBVNpY7Wa0bWp11AgdPMjdrsagxLBRHLvyIcagrvhDgxvlyKC3LU
eBX/ZQ7kQ3TZcOcu91sz5Q//BPekdrU1H1L4ddoZaLS7tC61aRRufQdJmQk/1JB+DDBJj+966Mjb
wtbAaSR9hHeUrXYStI4vr0eZN+kah3J724ysG3Ohk7i4gh0XeIqmPcn3eIqtRYjoiENL6hLZtyMb
319f4fsUB1qf/Rgoe6RzVWhD0qBOtl3abCEurgSFJUztV3i3UZTrCeesvSc5t5T0KotRFJyIZpag
rdnsLiCt9sx378JiSYvZyh7g9aI70kZBRM4zlP8AAAAAAAA=

--=-H+nUPs1cUv+b2JQsJxx7--

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 n44HLKBC060640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 10:21:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44HLKEc060639; Mon, 4 May 2009 10:21:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44HL9fc060629 for ; Mon, 4 May 2009 10:21:19 -0700 (MST) (envelope-from [email-masked])
Received: from skaro.afraid.org ([212.169.1.61]:21902) by relay01.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.41]:1325) with esmtp id 1M11qk-0002WV-45 (Exim 4.69) (return-path ); Mon, 04 May 2009 18:21:06 +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 5D21F5D65; Mon, 4 May 2009 18:21:03 +0100 (GMT/BST)
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 19:21:03 +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: Changing GPG's default key type
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 4/5/09 16:40, David Shaw wrote:
> We are currently thinking about changing the default primary to
> a 2048-bit RSA key.

I see no problems here, I would agree with the shift to RSA 2048 as the
default.

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 n44FVMU1052728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 08:31:23 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44FVMb5052727; Mon, 4 May 2009 08:31:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44FVB9L052711 for ; Mon, 4 May 2009 08:31:22 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 49473 invoked from network); 4 May 2009 15:31:09 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay00.pair.com with SMTP; 4 May 2009 15:31:09 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 11:32:04 -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: New results against SHA-1
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0EEC22D02892A3EDBBB25B03"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0EEC22D02892A3EDBBB25B03
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 04/30/2009 06:39 PM, David Shaw wrote:
>=20
> http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf
>=20
> There is not much hard information yet, but the two big quotes are
> "SHA-1 collisions now 2^52" and "Practical collisions are within
> resources of a well funded organisation."

Ugh. i didn't think this would happen this soon.

I'd like to formally suggest that we need to re-open this working group
and begin discussion on a new revision of the OpenPGP draft.

Whether or not the above report turns out to have legitimate theoretical
grounding (i've only read the abstract, and don't know if my math would
be sufficient to evaluate a full report anyway), we know that there are
explicit dependencies on SHA-1 in OpenPGP that need to be made more
flexible.

Here are some key points that need to be adjusted w.r.t. digest algorithm=
s:

a) Fingerprints: these are currently SHA-1 hashes of the public key
mateerial. One proposal is to continue hashing the exact same data but
to prefix the fingerprint with the canonical name of the digest
algorithm used, separated by an unambiguous delimiter (i'm using -
because : seems pretty overloaded in a lot of places, but i'm sure we
can collaboratively choose a good delimiter). So in that case, my
current fingerprint would be re-written as:

SHA1-0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

b) fix the Revocation Key (subpacket 12) to indicate digest algorithm
and variable length data. A poorly-worded attempt at a revision:

5.2.3.15. Revocation Key

(1 octet of class, 1 octet of public-key algorithm ID, 1 octet of
digest algorithm, N octets of digest)

Authorizes the specified key to issue revocation signatures for this
key. Class octet must have bit 0x80 set. If the bit 0x40 is set,
then this means that the revocation information is sensitive. If bit
0x20 is unset, the digest algorithm is assumed to be SHA-1, and no
octet identifying the digest algorithm is included. Implementations
SHOULD set bit 0x20 and explicitly include the hash identifier.
Other bits are for future expansion to other kinds of authorizations.
This is found on a self-signature.

If the "sensitive" flag is set, the keyholder feels this subpacket
contains private trust information that describes a real-world
sensitive relationship. If this flag is set, implementations SHOULD
NOT export this signature to other users except in cases where the
data needs to be available: when the signature is being sent to the
designated revoker, or when it is accompanied by a revocation
signature from that revoker. Note that it may be appropriate to
isolate this subpacket within a separate signature so that it is not
combined with other subpackets that need to be exported.

c) settling on a new "lowest-common-denominator" hash aside from SHA-1
(or discarding the idea of a lowest-common-denominator hash?)

Some other possible changes:

d) suggesting new defaults for key choices (does this mean avoiding
DSA1, for example, or other algorithms that rely on 160-bit hashes?)

e) allow injection of arbitrary key material at the head of signatures
to allow signers to to avoid a chosen-prefix attack? This would make it
significantly more difficult to predict the hash that someone will sign,
which makes birthday attack collisions more difficult to pull off since
the signer cannot be compelled to sign a particular hash.

f) explicit introduction of new hashes/ciphers/asymmetric algorithms?

I've probably missed something. What else should be addressed? What
steps are necessary to get the WG back in order again? Or is that not
needed?

--dkg

--------------enig0EEC22D02892A3EDBBB25B03
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

iQIVAwUBSf8KeczS7ZTSFznpAQo3VQ/9EnJgcDEjIxKrIZaWX8JR5fRyyVyEGN0C
1UPPOE7YB6sOScQPAhE7+6S65sekfcMIlhGPMSsPu6QkxjRCHo7P6sRcJ9C8tZY1
vIxumm5zFzrxvGla1IIiLqgMXaQyjD/11AGwV4pWJxdMa5eFPVElz8/EHggmXkbG
GKg7jY/m3Rbkjabkc87rD6+ZkzBRJDq1kKQ8ep13Ucp4u8w80njWKYaJa0fe4vDx
VYbkZVOvVN3A0QYGXOrdmkpDry9XbXbrBmZxMo93a1MA1h6s8wd5TOQcoZAkTR92
mDcrbRFbeU1gOmXLfnfL9nXEj+gOf6BGF+dZILgaxEPsmPYwbJ3OvddKbBzcA2cu
Mulv38iaWsFNeuvNLC12SE12I9T8dxywKnaHGL7O1RB9kGBWYYHsDGzthLqkvBEF
UKlqZ41M8vR+xvSA6SBKl9qAcuyO+a4pObHmOMCjmiTBjmtAjsGAo6O+E9rNuSSa
r76rNk/DgA81bjzTUNMc3+8qv+UwBulU3dFIfD9chWI9TVQCi43PcoQcCdvlnm0e
e7JRZuGGuQfzaSzJg0LHgAoVUY9QOKsaS7c7TFbDS/vEnQCmzEkaSo512PzLAwwn
fwE0h+kHJU087If950aujlRnu/7a8KcJiyGig4aZRYOXu6kZe4iQjnr5l+RpdRXP
ycwuZiPEKTA=
=q4zH
-----END PGP SIGNATURE-----

--------------enig0EEC22D02892A3EDBBB25B03--

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 n44Ef55i048913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 07:41:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44Ef5lx048912; Mon, 4 May 2009 07:41:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] 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 n44Eerru048893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 07:41:05 -0700 (MST) (envelope-from [email-masked])
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 n44Eek5u019879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 May 2009 10:40:53 -0400
Message-Id: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group
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: Changing GPG's default key type
Date: Mon, 4 May 2009 10:40:52 -0400
X-Mailer: Apple Mail (2.930.4)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi,

Currently, GPG's default key type, the one that is recommended to all
new users, is a DSA primary key (1024 bits - not "DSA2") with an
Elgamal subkey. We are currently thinking about changing the default
primary to a 2048-bit RSA key.

The main benefits of changing the key type is that it can go past the
1024 bit DSA1 limit, and would also not be limited to a 160-bit hash,
both of which are getting a little long in the tooth. We could get
similar benefits with a DSA2 key, but DSA2 is not nearly as widely
implemented as RSA is, so is not a good option for a default key at
this time. We will of course continue supporting DSA2 (and DSA "1")
as we do now. This is purely a question of what the default key
should be.

This is not directly prompted by the recent SHA-1 troubles, but it is
somewhat related, as it would let users of the default key type use
hashes larger than 160 bits. That said, this is not intended to be a
fix for the SHA-1 problems. We are not proposing changing our default
signing hash, which will remain SHA-1.

After a bit of internal discussion, we thought it was worth mentioning
this here, to see if the OpenPGP community had any issue or other
comments. I don't expect this to be a particularly controversial
move, but discussion is always welcome.

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.

David