On 14 Dec 2005 10:47:21 -0800, Paul Rubin
<http://phr.cx@NOSPAM.invalid> wrote:
>Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
>> Ok, fellows time to say you still can't prove that, nothing is secure
>> and nothing can't be assumed. Anyway Thanks for highlighting the
>> hidden dependency factor, I believe I have now taken this as far as
>> can be resonable expected and I think now to be able to eliminate a
>> resonable amount of expected dependencies.
>
>Does it occur to you that the specialists who design hash primitives
>are trying to do the exact same thing, though in a more sophisticated
>way? Their constructions have been observed to still occasionally
>fail. Why do you think yours are better?
Because, I don't design the inner doings of those algorithms. I trust
their designers completely. The whirlpool / SHA512 hash outputs are
exactly as randomized and as the original designers made them. If I
reverse a CS-hash , I dont break it's fine construcion. If I combine a
CS-hash with an another CS-hash, I don't manipulate the goodness which
the original designers put to those hashes. Every single bit is still
there, in its originally intented surrounding context (even when
reversed)
The problem is that the original designers didn't tell when (/if)
their construct would be found broken. (Nor did they include any
instructions which would describe the potential dependencies which
their hash would bave with other hashes.) Therefore I asked ultimately
clearly what happens when a perfectly good and therribley bad hash
would be combined, and based received silent nicking I assume the
combination to be OK ( if hashes are truly independent). Offcause I
could join the whining crew and do nothing, but hey somebody must do
things others can whine about :)
I know you love my can-do attitude.
Regards
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
Received on Fri Dec 23 20:10:16 2005