Re: yet another hash algorithm
- From: Rade <rade.vuckovac@xxxxxxxxx>
- Date: Mon, 28 May 2012 20:58:17 -0700 (PDT)
On May 29, 5:38 am, orz <cdh...@xxxxxxxxx> wrote:
On May 27, 3:54 pm, Rade <rade.vucko...@xxxxxxxxx> wrote:
On May 25, 6:16 pm, orz <cdh...@xxxxxxxxx> wrote:
Leftward information flow occurs only in the addition of state->mixer.. Which is very slow.
Rightward information flow occurs only from the highest few bits.
Given those two details, I doubt it's possible to get a cryptographic
quality hash in much less than 64 rounds, as an attacker could attack
the lowest bit in isolation from the upper bits.
The purpose of the posting the algorithm is not seeking opinion but to
remember who used the novel techniques first.
This is the first time you have have talked about "remembering who
used the novel techniques first" in this thread. Or the linked
threads. Much of what you say doesn't seem to make sense in that
context. For instance, that implies that your previous algorithm was
an "unsuccessful try" because it did not remember who used the novel
techniques first, which seems rather bizarre.
Of course meaningful discussion is welcomed, but that also means that
the above statements need more substance.
My previous statements were a meaningful and substantive description
of fatal flaws in the described hash function. Good leftward and
rightward mixing are both essential elements in secure hashes and even
(to a lesser extent) in high quality checksum algorithms. Perhaps you
are unfamiliar with these concepts and/or this was of describing the
issues? Information flow here refers to which bits in one state
depend upon which bits in the prior state. Leftward information flow
here refers to the movement of information from less significant bit
position to more significant bit position, as in a "left shift"
operator in the C language. It happens very slowly during addition/
subtraction, and not at all during xor/and/or, but quickly during left-
shifts and some multiplications. Rightward information flow is the
equivalent in the other direction, as in a "right shift" operator in
the C language. Rightward information flow is a more common source of
problems, since it does not happen at all during any of the faster
standard operations (addition, bitwise xor, bitwise and/or/not, etc)
other than shifts.
Your standard "if (a > b) carry ^= ~c; else carry ^= c;" is equivalent
to "carry ^= c; carry ^= ((int64_t)(b-a)) >> 63;" which has some
rightward information flow, and technically some leftward information
flow as well, but in practice the leftward flow there is negligible
for the purposes of the lower bits, and the rightward is very
The statements from my previous post make it trivial to find two data
blocks that, when hashed using that algorithm, produce hashes that are
identical in the upper 32 bits of each 64 bit word, but differ in the
lower 32 bits of each 64 bit word. With a little additional work such
techniques could produce an attack that allowed the lowest bit or the
lowest several bits of each output word to be chosen arbitrarily by an
attacker, and independently of the upper bits.
For example the use of mixer variable is to balance amounts of ones
and zeros for inputs with low entropy (input with all zeros perhaps),
consequently if input has got enough entropy the mixer variable is not
The Motivation of the posting the algorithm is still who did it
first, not how successful the algorithm is.
Since the carry transformation is mentioned, below is short story.
The idea behind the algorithm is utilising McCabe Cyclomatic
Basically the carry is "xor sum" of all other previous elements in
Some array elements are obviously flipped, therefore calculation of
the sum can be in any of 2 ^ size states, meaning that transformation
is exponentially complex (Google above mentioned complexity and impact
of if / else in the program).
Then the carry updates element in array.
In this context statements mentioned above are not meaningful.
Previous try was easy to attack and it was shown by example not by
- Re: yet another hash algorithm
- From: Noob
- Re: yet another hash algorithm
- Prev by Date: Re: yet another hash algorithm
- Next by Date: Graphical Presentation – Displacement Crypto in a Nutshell.
- Previous by thread: Re: yet another hash algorithm
- Next by thread: Re: yet another hash algorithm