Re: yet another hash algorithm

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:

Meh.

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
limited.

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
needed.

Regards, Rade

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
Complexity.
Basically the carry is "xor sum" of all other previous elements in
array.
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
belief.

Rade
.

Relevant Pages

  • Re: what should "k-bit security" mean?
    ... What is the time t of an attack? ... algorithm to end of execution of the algorithm. ... Suppose the problem is inverting SHA1. ...
    (sci.crypt)
  • Re: what should "k-bit security" mean?
    ... |>An algorithm that provides X bits of strength would, on average, take ... And this is the measure that we used in the NTRU paper ... because some keys take so much less time than others to attack ... Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org ...
    (sci.crypt)
  • Re: Simple block cypher for 8-bit microcontrollers
    ... I do have specific applications in mind, but until I can be sure that the algorithm is correct, I'll be using other well known algorithms in my specific applications;) ... block ciphers. ... There are many variations on the basic slide attack. ...
    (sci.crypt)
  • Re: Algorithm Strength Scale
    ... therefore rendering it useless for serious purposes. ... It is arguable that this delivers an equivalent key in an equivalent algorithm, but it certainly does not recover the "functional key" of the original algorithm, and may not necessarily be possible to convert to the key itself. ... Admittedly, this is a significantly unusual form of attack, but it certainly violates the statement that there are "only ... ... It has no relation to reality, only serves to provide an appearance of thoughtfulness. ...
    (sci.crypt)