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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Mar 2014 12:32:28 -0800
From: "Dennis E. Hamilton" <>
To: <>
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 [] 
Sent: Friday, March 7, 2014 11:13
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 [] 
Sent: Friday, March 7, 2014 02:35
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