[Dshield] Crypto Question

[Frank Knobbe]

On Wed, 2009-03-04 at 17:41 -0500, Valdis.Kletnieks at vt.edu wrote:
> A man with one watch always knows what time it is. A man with 2 watches is
> never sure.

Depends on how you use the watches. Always trust #1 until it's dead,
then use #2. Yes the time might be slightly different, but it still
shows the time. (A completely misplaced analogy for the issue at hand
though... so lets forget about watches)

> In general, either that first hash is believed secure, or it isn't.  If it
> is secure, you don't need a second hash.  If you're worried enough about the
> first hash that using a second one is starting to make sense, you probably
> shouldn't be using the first one at all.
> 
> Or more concretely - if you're computing a SHA-256 hash because you don't trust
> the MD5 hash, maybe it's time to just *retire* the MD5 entirely.


Right. But you also said earlier that any hash algo is prone to
collisions. A method may not have been found or made viable yet, but
that possibility is there.

I think John's thought was, why not use two different hash algos on the
same plaintext. If one or the other fails (or both fail), something is
up. Only if both hashes (with known or unknown collision methods) pass,
the plaintext is verified.

Obviously that leads to complexity which may carry a little devil in
itself somewhere. Using a good hash that has a high reliability (SHA-512
or whatever) would be simpler.

But it raises an interesting question. We know mathematically how hard
or weak the known broken hashes are. How would you calculate the
combined reliability of two different hashes? Is it as simple as adding
exponents, or does it require a different strength calculation because
the algorithms are different and which inherently impedes finding a
single collision that satisfies both algos?

Just curious,
Frank



-- 
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part
Url : http://lists.sans.org/pipermail/list/attachments/20090305/def7a3d9/attachment-0001.bin