[Dshield] Crypto Question

John Hardin jhardin at impsec.org
Fri Mar 6 01:11:33 GMT 2009

On Thu, 5 Mar 2009, Valdis.Kletnieks at vt.edu wrote:

> The problem is when there is an *easy* way to generate *controlled* 
> collisions.

Okay, granted, I was assuming that context in my comments.

> And as I said before - if one of your hash functions suffers from that, 
> then it doesn't help to use a second hash to double-check.  You should 
> just *toss* the first hash, because any sane analysis will show there's 
> only three realistic states:
> 1) The first hash is genuine and valid so it passes, in which case a
>    check proves nothing.  Your second hash passes as well.

Two hashes passing is a _very_ good sign the data has not been altered.

> 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"?

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.

> 3) The first hash is a fake generated by an idiot, so it fails. Your
>    second hash probably fails as well.
> Look at that - the second hash is doing all the work, except if you get 
> attacked by an idiot.  So why you bothering doing the first hash at all?

Why have both seat belts and air bags in a car?

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.

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.

The use of a given algorithm has inertia. Not everyone will wish to - or 
be able to - discard a weak algorithm the moment a valid attack is 
demonstrated. Not everyone will generate new certificates when they become 
theoretically vulnerable. There is cost associated with making those 
changes, and that immediate cost may outweigh the perceived risk from the 
decision-maker's point of view. Not everyone will learn in a timely manner 
that their certificates or whatever are no longer trustworthy because the 
hash has been broken. And not all data integrity signatures are ephemeral, 
where changing the hash algorithm is an option.

I am not disagreeing with your point that a known broken hash algorithm 
should be replaced where that is possible. What I am lamenting is that the 
communication protocols and file formats that use cryptographic hashing to 
ensure data integrity have (universally, as far as I know) _not_ 
implemented this very simple redundancy mechanism to remain reliable in 
the face of a successful attack on a given hash algorithm.

I don't understand why you're having such a negative reaction to this.

  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin at impsec.org    FALaholic #11174     pgpk -a jhardin at impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
   Failure to plan ahead on someone else's part does not constitute
   an emergency on my part.                 -- David W. Barts in a.s.r
  3 days until Daylight Saving Time begins in U.S. - Spring Forward

More information about the Dshield mailing list