Re: Added hashes.

On 13 Dec 2005 12:28:43 -0800, Paul Rubin
<http://phr.cx@NOSPAM.invalid> wrote:

>Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
>> What I claim is that a combination of one _PERFECTLY GOOD_ hash with
>> one equally long but terrible bad-hash, results a third hash, where
>> the faults caused by bad-hash are hidden PERFECTLY.
>
>But that is a useless thing to know. The reason you're trying to
>combine these hashes is that you suspect that neither of them is
>perfectly good.

You are right that is exactly the case. (Are you sure you are not an
Asian guru.) I suspect that one day one of the hashes Whirpool or
SHA512 will eventully fall, because the history of hashes says so. Ok,
none of those is perfect, but let's assume one of those would fall
sooner than the other.
    If the other would fall and the other remain completely
unaffected, would it seem likely possible or unlikely that a
combinatory hash could hide the faults of the one that will be found
first bad.

>If one was perfectly good, you would just use it.

Perfect individuals do not evolve :)

>If neither is perfectly good, then the combination might be worse than
>either one separately.

1) Hey "If neither is perfectly good, then..." does that mean that you
slightly agree with what was 'claimed': a perfectly randomized
perfect hash in combination with poor performing hash (made in: world
of sin) --> all weaknesses resulting third hash will disappear,
(provided that the hashes are truly independent and equally long)

>If neither is perfectly good, then the combination might be worse than
>either one separately.

2) Ok, (if) both are less than perfect... problems?
- The third hash would / could have derived the badness from both then
the faults would/could exists even in third-hash,
        -->Ok sounds resonable
- But could the combination break 2 other vice 'nice' hashes and make
the third-hash 'bad'? The mechanism would then have to reverse some of
the rounds (/passes) which the 'nice' hashes normally do.
        -->Sounds weird, of cause it would make sense if the third
hash would be build gradually after each pass of the 'nice' hashes.
Then hash1 could reverse the action of hash2. But to think that if
hash1 is calculated ready and then hash2 is calculated and added. And
the hash2 would introduce faults to the result of hash1 ??? Then why
not always use hash2 in exposing hash1 preimage collisions.

>Trivial example: two hashes F and G. F is sha1, a pretty good but not
>perfectly good hash. G is also sha1, a pretty good but not perfectly
>good hash, just like F. The combination (F xor G) is all zero, a
>useless hash.

As Phil mentioned, description in my second post does lack the word
independet (damn) - should be included

>Where that leads: if F and G aren't identical, they still might be
>correlated in some way.

Yes, That is part of the the scary part

> If you have a way to prove they are not,
>you're likely pretty close to being able to prove that one of them is
>perfectly good.

Somehow I think that, proving that would not to be trivial :)

Regards
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
Received on Fri Dec 23 20:10:07 2005