Confusion with signature digest type.

[Daniel Kahn Gillmor]

On 04/28/2013 04:26 AM, Robert J. Hansen wrote:
> On 4/27/2013 8:01 PM, Daniel Kahn Gillmor wrote:
>> I don't think this recommendation was made to defend against preimage
>> attacks.  Avoiding the use of SHA-1 in certifications in general is a
>> step towards defend against collision attacks, which is territory that
>> SHA-1 is heading into.  (i agree that if sha-1 falls victim to preimage
>> attacks we have much much bigger problems).
> 
> I'm having a little bit of trouble connecting the dots, Daniel.  (This
> may be due to the late hour: at 4:30am I'm only awake due to a caffeine IV.)
> 
> If I sign my certificate using SHA-1 today, how does that facilitate a
> collision attack against that certification?

It doesn't facilitate a collision attack against that specific
certification; but if a collision attack is possible against a
particular digest, then *any* signature made over that digest becomes
suspect.

That is, should a collision attack become viable against a particular
digest, there's no way to tell whether any given signature that uses
that digest was made before or after the collision attack was possible.

So responsible clients that want to ensure that their certifications
(including self-certifications) are acceptable to their more
security-conscious peers should ensure that their certifications don't
use digests that are at risk of collision attacks.

For example, let's say you're in the habit of regularly signing a
changing collection of data for $job, and those signatures use SHA1.  An
exploit comes along against SHA1 that renders it vulnerable to collision
attacks.  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).

Eve waits for you to make your regular data collection signature, and
then rips it out and attaches it to your primary key, thereby creating
an assertion that you have a new identity that you wish to be public and
associated with your old ones.

granted, this is not the end of the world (we all know that your e-mail
address isn't really president at whitehouse.gov), but anyone who believes
SHA-1-based certifications won't be able to tell whether rjh thinks he
is the President of the USA or whether the President thinks he is rjh.

You can avoid all of this by making all of your certifications
(including your self-sigs) over a widely-accepted digest that is not
thought to close to the risk of collision attacks; SHA-256 seems like a
reasonable choice.

There is no good reason for anyone interacting with modern
infrastructure to make their default certifications with anything weaker.

For the few people who need to ensure that their key can be accepted by
legacy systems that don't support SHA-256, systems that want to be
legacy-compatible could issue each self-sig in duplicate form: one using
SHA1, timestamped at N-1 seconds since the epoch, and the other using
SHA256, timestamped at N seconds since the epoch.  Modern tools that can
interpret the SHA256 certification would use it (and ignore the older
cert that uses the weaker digest) and  legacy SHA2-incapable systems
could interpret the older cert.

does this make the concern (and one approach to addressing it) more clear?

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/20130501/206b3bcc/attachment.sig>