On 2005-02-19 10:58:23 +0100, exon wrote:
Michael Silk wrote:
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 + hashFunc1(input) + salt )
//
// instead of
//
result = hashFunc1( input + salt )
--
I assume you mean hashFUnc2 inside the parentheses (I'll refer to it as
that anyway, for clarity).
I don't think so. Hashing functions for login (e.g., the BSD/Linux style
MD5-hash) usually call the same hashing function multiple times.
No it won't, because if hashFunc2 has collisions the resulting output
will collide in hashFunc1 as well.
No, it wont. (input1 + hashFunc2(input1)) and (input2 +
hashFunc2(input2)) are still different strings, even if
hashFunc2(input1) and hashFunc2(input2) collide, so you have to find an
input which collides in both hashes (well, not quite), which should be
harder to find than one which collides in only one.
If you didn't mean hashFunc2 inside the parentheses, you have actually
lessened the collision resistance, owing to the possibility that two
different outputs might collide as well.
No, because again, (input1 + hashFunc1(input1)) and (input2 +
hashFunc1(input2)) are two different strings, even if hashFunc1(input1)
and hashFunc1(input2) collide, and they must collide as well.
hp
--
_ | Peter J. Holzer | If the code is old but the problem is new
|_|_) | Sysadmin WSR / LUGA | then the code probably isn't the problem.
| | | hjp@wsr.ac.at |
__/ | http://www.hjp.at/ | -- Tim Bunce on dbi-users, 2004-11-05
pgp5T55x5TiMu.pgp
Description: PGP signature
