[Dshield] Crypto Question

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Fri Mar 6 19:46:34 GMT 2009

On Thu, 05 Mar 2009 17:11:33 PST, John Hardin said:
> On Thu, 5 Mar 2009, Valdis.Kletnieks at vt.edu wrote:

> > 2) The first hash is a fake generated by a clued adversary, so it passes
> >    anyhow. The check still proves nothing. Your second hash fails.
> What do you mean here by "The check still proves nothing"?

It means "looking at the first hash, you *know* it's weak, and therefore you
have no *clue* whether the hash passed because it was valid, or because it
was forged".

Imagine a 2-step check if a 5 dollar bill is counterfeit or not:

1) Check if it has a 5 on it, and a picture of Lincoln.  This is the
equivalent of a known-weak hash - anybody could have faked *this* part
well enough to pass, unless they're a total idiot.
2) Check for watermarks, microprinting, the Orion constellation, the security
strip, and all the other documented anti-counterfeiting measures.

What are the chances that (1) is actually going to catch anything?  Or are
you relying on (2) for any *real* security here?
> You can say that the data is suspect and should not be trusted. Which you 
> cannot do when you only have one hash using the broken algorithm.

Exactly - that's the whole point - since the hash using the broken algorithm
*CANT TELL YOU* that it's suspect, why are you bothering to check it?

> I'm using the first hash algorithm because at the time I generated that 
> certificate the attack on the first hash algorithm was not known. I'm 
> _still_ using the first hash algorithm because that legal document was 
> electronically signed five years ago, before the attack on the first hash 
> algorithm was known.

And guess what?  That's actually probably *not* an actual problem, simply
because it *was* signed before the attack was known.  Unless your threat
model involves that document having been forged by ninja crypto wizards
before the attack was published (in which case you probably have bigger
problems, since you're being attacked by seriously well-funded adversaries),
you can simply say "this was known to have been signed 2 years before anybody
could have forged it, so it is probably OK".

Yes, there's a small hole there.  However, you only actually *care* about
that hole *after* you've dealt with all the *other* little details - such as
the fact that "it was signed with your key" is not the same thing as "you
signed it".  All the signature proves is the data and the key were present
at the same place at the same time - it doesn't prove that you actually
intended to sign *that* document rather than some bait-n-switch.  See any
Mel Brooks or Marx Brothers movie that includes "Sign here.. and here.. and
here.. and here.. and here.." for *that* attack.  It also doesn't prove that
the key wasn't purloined by malware - another actual threat when a high
percentage of end users are on Windows boxes that have malware on them.

http://xkcd.com/538/ sheds some light onto the *actual* threat models here.

Or read the chapter in Schneier's "Secrets and Lies" on why PKI is by and
large snake oil.

Once you've dealt with all *those* issues, *then* we can sit down and discuss
what the ninja crypto wizards did with the signature before an attack was

> You seem to be ignoring the time frame between when an attack is 
> discovered and starts being used and when the vulnerable hash is no longer 
> being used to protect data integrity.

I'm *intentionally* ignoring it, for a very good reason - good crypto systems
do *not* usually fail all at once (feel free to provide counter-examples).
They fail incrementally, over years, as better attacks get published.  The
end result is that if you're *still* using something by the time the attacks
become feasible in real life, it means you failed to start migrating 5 or 6
years ago when the first, not-real-life-feasible, attacks showed up.

Yes, you can go ahead and whine "but I have this embedded system up in a
satellite/on a mountaintop/done in hardware and I can't change the algorithms
now".  All I can say there is "You should have consulted a crypto expert
when you built the damned thing and thought about how you'd address this exact
problem down the road".

OK? I'll repeat it one more time:  The *ONLY* reason that somebody was able to
demonstrate the recent CA certificate hack was because the victim CA was over
*5 years* behind the times in migrating off *known weak* methods.

How much slack would you get if your system got hacked because you hadn't
patched a hole that was published 5 years ago?  Not much?  Well then, why
are you trying to let the crypto side get off any easier?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.sans.org/pipermail/list/attachments/20090306/4bb0218b/attachment.bin 

More information about the Dshield mailing list