Re: SHA-1 broken

From: Michael Silk (michaelsilk_at_gmail.com)
Date: 02/20/05

  • Next message: Gary H. Jones II: "Gigafast/CompUSA router (model EE400-R) vulnerabilities" 
    Date: Mon, 21 Feb 2005 08:58:54 +1100
To: bugtraq@securityfocus.com, exon@home.se

    Inline.

    > -----Original Message-----
    > From: exon [mailto:exon@home.se]
    > Sent: Saturday, 19 February 2005 8:58 PM
    > To: bugtraq@securityfocus.com
    > Subject: Re: SHA-1 broken
    >
    > Michael Silk wrote:
    > > Michael,
    > >
    > > But wouldn't it render a login-based hashing system
    > resistant to the
    > > current hashing problems if it is implemented something like:
    > >
    > > --
    > > result = hashFunc1( input + hashFunc2(input) + salt )
    > > //
    > > // instead of
    > > //
    > > result = hashFunc1( input + salt )
    > > --
    > >
    >
    > I assume you mean hashFUnc2 inside the parentheses

    Yes.

     
    > No it won't, because if hashFunc2 has collisions the
    > resulting output will collide in hashFunc1 as well.

    How?

    The attackers input is "input". He can only choose to enter a
    collision for "hashFunc1" _OR_ "hashFunc2". He can't enter a
    collision for both, but that is what he needs to pass this
    function with a different string from the original.

    > The
    > collision resistance in this case is somewhat less than that
    > of hashFunc2 (because two different outputs of hashFunc2
    > might collide in hashFunc1,

    Sure, hashFunc2 might give collisions, but it doesn't mean anything
    unless _THOSE_ collisions are collisions in hashFunc1 that lead to the
    original hash.

    > but a
    > strong hash isn't supposed to depend on the algorithm not being known.

    Obviously.

    -- Michael

  • Next message: Gary H. Jones II: "Gigafast/CompUSA router (model EE400-R) vulnerabilities"
    • Quantcast