Jerrold Leichter wrote:
>Joux's attack says: Find single block messages M1 and M1' that collide on
>the "blank initial state". Now find messages M2 amd M2' that collide with
>the (common) final state from M1 and M1'. Then you hav four 2-block
>collisions for the cost of two: M1|M2, M1'|M2, and
Jerry Leichter writes:
> It all depends on how you define an attack, and how you choose to define your
> security. I explored the "outer edge": Distinguishability from a random
> function. For a random function from {0,1}*->{0,1}^k, we expect to have to do
> 2^k work (where the unit of work is a
| > However ... *any* on-line algorithm falls to a Joux-style attack. An
| > algorithm with fixed internal memory that can only read its input linearly,
| > exactly once, can be modeled as an FSM. A Joux-style attack then is: Find
| > a pair of inputs M1 and M1' that, starting from the fixed ini
On Fri, 27 Aug 2004, Hal Finney wrote:
>Jerry Leichter writes:
>> However ... *any* on-line algorithm falls to a Joux-style attack.
>That's an interesting point. One counter example I can offer is my
>earlier suggestion to use a wide path internally between the stages.
>The analysis suggested
Jerry Leichter writes:
> However ... *any* on-line algorithm falls to a Joux-style attack. An
> algorithm with fixed internal memory that can only read its input linearly,
> exactly once, can be modeled as an FSM. A Joux-style attack then is: Find
> a pair of inputs M1 and M1' that, starting fro
| Bear writes:
| > One interesting idea which I came up with and haven't seen a way
| > past yet is to XOR each block with a value computed from its
| > sequence number, then compute the hash function on the blocks in
| > a nonsequential order based on the plaintext of the blocks
| > in their n
On Wed, 25 Aug 2004, Hal Finney wrote:
>Bear writes:
>> One interesting idea which I came up with and haven't seen a way
>> past yet is to XOR each block with a value computed from its
>> sequence number, then compute the hash function on the blocks in
>> a nonsequential order based on the plain
Bear writes:
> One interesting idea which I came up with and haven't seen a way
> past yet is to XOR each block with a value computed from its
> sequence number, then compute the hash function on the blocks in
> a nonsequential order based on the plaintext of the blocks.
>
> In concrete terms, you
On Wed, 25 Aug 2004, Hal Finney wrote:
>Dan Carosone writes:
>> My immediate (and not yet further considered) reaction to the
>> description of Joux' method was that it might be defeated by something
>> as simple as adding a block counter to the input each time.
>
>Right after the talk, Scott Fl
Hal Finney wrote:
Another of the Crypto talks that was relevant to hash function security
was by Antoine Joux, discoverer of the SHA-0 collision that required
2^51 work. Joux showed how most modern hash functions depart from the
ideal of a random function.
The problem is with the iterative nature
Dan Carosone writes:
> My immediate (and not yet further considered) reaction to the
> description of Joux' method was that it might be defeated by something
> as simple as adding a block counter to the input each time.
Right after the talk, Scott Fluhrer (I think it was) spoke up with
several qui
My immediate (and not yet further considered) reaction to the
description of Joux' method was that it might be defeated by something
as simple as adding a block counter to the input each time.
I any case, I see it as a form of dictionary attack, and wonder
whether the same kinds of techniques woul
Jerry Leichter writes:
> Joux's attack says: Find single block messages M1 and M1' that collide on
> the "blank initial state". Now find messages M2 amd M2' that collide with
> the (common) final state from M1 and M1'. Then you hav four 2-block
> collisions for the cost of two: M1|M2, M1'|M2, a
| > It strikes me that Joux's attack relies on *two* features of current
| > constructions: The block-at-a-time structure, and the fact that the state
| > passed from block to block is the same size as the output state. Suppose we
| > did ciphertext chaining: For block i, the input to the compre
Jerry Leichter writes:
> It strikes me that Joux's attack relies on *two* features of current
> constructions: The block-at-a-time structure, and the fact that the state
> passed from block to block is the same size as the output state. Suppose we
> did ciphertext chaining: For block i, the inpu
It strikes me that Joux's attack relies on *two* features of current
constructions: The block-at-a-time structure, and the fact that the state
passed from block to block is the same size as the output state. Suppose we
did ciphertext chaining: For block i, the input to the compression function
i
Another of the Crypto talks that was relevant to hash function security
was by Antoine Joux, discoverer of the SHA-0 collision that required
2^51 work. Joux showed how most modern hash functions depart from the
ideal of a random function.
The problem is with the iterative nature of most hash func
17 matches
Mail list logo
