[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000001cf3a44$5ca26f10$15e74d30$@acm.org>
Date: Fri, 7 Mar 2014 12:32:28 -0800
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
Subject: RE: [PHC] Are password trailing 0's a problem?
One more PS.
When prehashing is done to ensure that different passwords don't collide, even if the difference is nulls on the end, it is also useful to concatenate the salt on the end.
In some uses of PBKDF2, it discourages bypassing the prehashing with known hashes. I don't know if that is much consideration for TigerKDF though.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@....org]
Sent: Friday, March 7, 2014 11:13
To: discussions@...sword-hashing.net
Subject: RE: [PHC] Are password trailing 0's a problem?
[ ... ]
I believe others have suggested the appropriate remedy: Pre-hash the key. In effect, the key that is input to PBKDF2 is a hash value that is the same size as the PRF output block size. This also allows streamlining of the setup for the HMAC and its iterative cycling.
[ ... ]
-----Original Message-----
From: Bill Cox [mailto:waywardgeek@...il.com]
Sent: Friday, March 7, 2014 02:35
To: discussions@...sword-hashing.net
Subject: [PHC] Are password trailing 0's a problem?
I noticed that any password used in PBKDF2 gives the same result as
that password with 0's appended any number of times up to a total
length of 64 bytes. Is this a problem? A way around this would be to
add the password length to the data hashed. Since I always call
PBKDF2 with c ==1 (1 repetition), this is the only input parameter
which can change without changing the output.
[ ... ]
Powered by blists - more mailing lists