bugtraq - Re: SHA-1 broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4219A322.7050507@home.se>
Date: Mon, 21 Feb 2005 10:00:18 +0100
From: exon <exon@...e.se>
To: bugtraq@...urityfocus.com
Subject: Re: SHA-1 broken


Michael Silk wrote:
> Inline. 
> 

Naturally. Likewise.

> 
>>-----Original Message-----
>>From: exon [mailto:exon@...e.se] 
>>Sent: Saturday, 19 February 2005 8:58 PM
>>To: bugtraq@...urityfocus.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.
> 

if(HF2(xxx) == HF2(XXX))
then
HF1(HF2(xxx)) == HF1(HF2(XXX))
regardless of collisions in HF1, since HF1 is fed the same input for 
both those inputs. In effect, this means that if HF1 is a perfect hash 
(no collisions, ever) it would still collide because it is given the 
same input from HF2.

To force a collision to exist in both hashes you would have to do 
something like this, which was posted to this list erlier by someone 
whose name I can't recall (assume + means concatenation)
output = HF1(input + HF2(input))

Note that this is just off the top of my head and would most likely 
depend on the algorithms used, but the input MUST be fed unaltered to 
both hashing functions for it to be any stronger than the original 
implementation (in theory, that is).

/exon