Confusion with signature digest type.

[Daniel Kahn Gillmor]

On 05/02/2013 12:03 AM, Robert J. Hansen wrote:

>> Eve manages to inject data into your collection that makes the
>> data collection have the same digest as a particularly weird User ID
>> when bound to your primary key (i'm handwaving past the details of the
>> OpenPGP boilerplate involved in a self-sig here).
> 
> Are you sure that this is a collision attack?  It seems to me you've
> created a preimage scenario here.  And if so, I stand by my statement of
> "then I'm completely screwed on a dozen different fronts simultaneously
> and my certificate is the least of my worries."  :)

if it was a preimage attack (even for SHA1), then yeah, it'd be game
over in a lot of horrible ways i don't want to think about in detail
right now :)

It's a collision attack based on the idea that:

 a) Eve can inject arbitrary data into the collection that she expects
you to sign, and

 b) Eve can inject arbitrary data into the self-sig that she's crafting
(e.g. in a "tumor" in non-critical subpackets of the Eve-generated
self-sig).

So Eve's work is to manipulate both X (the data repository) and Y (the
self-sig she's crafting) until she can coax them into a collision.  She
doesn't care what the collision is, so she's not involved in a pre-image
attack.

As i understand it, this is roughly analogous to the attack used against
rapidssl in http://www.win.tue.nl/hashclash/rogue-ca/, which exploited
cryptogrpahic weaknesses in MD5's collision resistance to mint an
exploitable intermediate CA.  In that attack, they manipulated X (the
expected serial number and timestamp and distinguished name in the X.509
cert generated by RapidSSL) and Y (the "tumor" in their bogus,
handcrafted intermediate X.509 CA cert) until they found an MD5
collision, and then got RapidSSL to issue the predictable cert at the
expected timestamp with the expected serial number.  Once the X.509 cert
was issued, they spliced the good signature onto the bogus cert, and had
themselves a cert that any browser would accept.

If you think this analogy doesn't hold, please let me know where it
falls apart.

>> There is no good reason for anyone interacting with modern
>> infrastructure to make their default certifications with anything weaker.
> 
> I continue to think that you're worrying about how you're going to turn
> the coffeepot off as you're fleeing a house fire.  :)

I still maintain that encouraging people to use SHA-1 for any
certification (including self-sigs) is leaving the coffeepot on, but the
house is not yet on fire.  Let's turn off the coffeepot :)

SHA-1 is a fine digest for fingerprints, which are generated from
material entirely under the user's control, and cannot be influenced by
an outside party, and can never be confused or substituted by such
things.  this is because fingerprints rely on preimage resistnace,   But
it is ill-advised to make new signatures over any digest that has
significantly weakened collision-resistance; this is particularly true
when stronger digests are widely available, as is the case with SHA-256.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130502/61a48fc1/attachment.sig>