[Dshield] Crypto Question

[John Hardin]

On Fri, 6 Mar 2009, Valdis.Kletnieks at vt.edu wrote:

> On Thu, 05 Mar 2009 17:11:33 PST, John Hardin said:
>
>> 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?

Because *at the time the hash was generated* the weakness was not known, 
or was only theoretical.

I believe I understand the failure to communicate here. You are saying 
"why _keep using_ a known weak algorithm?" I agree with you, and I am not 
arguing that should be done (though I recognize in practice it _will_ be 
done, and that should be planned for by the designer).

I am saying "Why rely solely on one algorithm for security when it likely 
has unknown weaknesses? Why not design your protocol or file format to not 
silently fail when a weakness is discovered in that algorithm?"

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

I'm postulating an attack that allows substitution of a given alternate 
text for the originally signed text, which is very unlikely. To quote your 
other email:

> What *IS* known is how to generate two bitstreams that have the same MD5 
> hash, except you don't have any real control over what the two 
> bitstreams end up being, or what the hash is

So I recognize it's unlikely post-facto.

Given my scenario, though, if such a collision failure is discovered, then 
you cannot trust _any_ document that was _ever_ signed using that 
algorithm - how do you know the text of the document hasn't been 
substituted using that attack? Preventing that would be cheaply and easily 
avoided by not relying on just one hash algorithm.

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

Agreed.

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

Again, agreed.

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

To avoid an easily-avoidable single-point-of-failure flaw.

I don't dispute any of your points. And I agree that a failure mode that 
allows substitution of Plausible Plaintext #2 having the same hash as 
Original Plaintext #1 is unlikely in the extreme.

What I don't understand is why you're apparently so hostile to the idea of 
adding redundant hashes as another layer of trustworthiness. Is the extra 
complexity and computational cost truly _that_ great?

-- 
  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
-----------------------------------------------------------------------
  Today: Daylight Saving Time begins in U.S. - Spring Forward