Re: Added hashes.

On Tue, 13 Dec 2005 22:55:41 +0000 (UTC), daw@taverner.cs.berkeley.edu
(David Wagner) wrote:

>Juuso Hukkanen wrote:
>>Paul Rubin wrote:
>>>If neither is perfectly good, then the combination might be worse than
>>>either one separately.

(post contains a method for eliminating (most) hidden dependencies
between combined hashes (shown at end))

Thank you, I stress (with) this question because it needs to be
answered - the more precise the better..

>Maybe you're having trouble imagining how this could happen in practice,
>but in principle there is no good way to rule out the possibility.

I have no reason to doubt that any computer security related solution
can be somehow made to fail. All encryption algorithms, all crypto
devices, all users, all all.

>See my note, or Paul Rubin's note, for justification. In practice it
>seems like it would be very surprising if the combination was worse
>than the two components, for any reasonable choice of two components,

As Paul points every security failure must be expected to happen, if
not provable othervice. Causing any non-proven solution to be
theoretically insecure, including AES, RSA, ECC etc. pretty much
everything else than secure proved OTP.

What I try to do is to take some of the divine power of OTP, and
transfer it first to hashes and then transfer those hardened hashes to
form a cipher. From that follows that an attacker can be forced into a
a single 'alley' where the only way to break the cipher requires
breaking that hardened hash. Doesn't that kind of defence starategy
sound better, than to trust in something which may be attacked using
all kinds of unholy holes, rotations, timers, shifts, jumps, loops
which the original designers had desided to put into a cipher.

The problem is obtaining a hash, and all hashes seem to be falling
sooner or later. AND I don't wan't to make such a hash based cipher
which would fail as soon as a hash fails. Therefore I askthis direct
theoretical question:
******************
If a (theoretical) PERFECTLY randomized good hash would be combined
with a (indepoendent but) bad hash, wouldn't the resulting third-hash
be PERFECTLY random?
(YES / NO)
******************
I understand that nobody is willing to direcly confirm that clause to
be true, but the answers are more like the ones politicians give on
unpopular issues.

You say: "...then XOR-ing might be safe".
Paul hints: "If neither is perfectly good, then the combination might
be worse than..." (leaving room for possibility that if at least on is
perfectly good then the question might safe).

 I assume the marked question to be true (identical with OTP -
system). Meaning that IF I have a PERFECT hash I can combine it with
independent equally long plain texts 1-1000000 times and the end
result will always remain PERFECTLY secure ( no patterns, no biases,
no hints).

But as you point out there are no PERFECT hashes and there is no way
to prove their independence. --> the facts I must live with

>but what I'm saying is that it is not guaranteed by any theorem --
>there is no way to prove that bad things cannot happen.

Ok, security is about risk managent. On the other hand the concept of
layered defences is a widely accepted secuity method.

>Sure, if we somehow knew that the two hashes were "independent" (whatever
>that means), then xor-ing them might be safe. But we don't know how
>to verify with certainty that a pair of hashes is independent, any more
>than we know how to verify with certainty that a single hash is secure.
>Out of the frying pan, into the fire.

*********
Improving quality of combined hashes:

1) calculate Whirlpool
2) calculate SHA512
3) form a third hash by combining Whirlpool with SHA512 using a
modulus addition
4) reverse the third hash (by bytes) --> forms fourth hash
5) form a fifth hash by combining Whirlpool with SHA512 using XORing
6) form a sixth and _final_ hash by modulus addition of third and
fourth hash.

<==> why independency would improve
a) Only one perfect and independent hash is needed, because is such is
obtained it will infect its perfectness into all strings which it is
to be combined.

d) if a small hidden dependency would exist ( whirl +SHA), such would
likely manifest as a small bias in single bit(s) or byte value(s).

c) combining (sha- and whirl ) hashes using XOR and modulus addition
creates two new hashes (third and fifth) . In which there may still be
per byte measurable dependencies ( XOR:ing of byte's bits and
calculating their value are not unrelated.

b) however when combining the fourth and fifth hash, each combined bit
describes properties of a different byte. 512 bits is 64 bytes i.e.
when the third hash was rotated, all the bytes changed position.

e) Even if there might be a hidden structural dependency between
SHA512 and Whirlpool, the bytes in fouth and fifth hash describe each
byte using two bytes( derived from the Sha / whirlpool) and if one of
those two bytes is independent, the result byte will no longer have a
calculable dependencies. ( if both bytes had a dependency problem, it
might still be present)
*********

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.

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