Message-ID: <00a201cf3a39$386abd60$a9403820$@acm.org>
Date: Fri, 7 Mar 2014 11:12:42 -0800
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
Subject: RE: [PHC] Are password trailing 0's a problem?

To be more definite about all of this, the characteristics being concerned about are determined by the PRF used in PBKDF2.

In the case of HMAC-SHA1 as the PRF, there is an useful note about that in Appendix section B.1.1 of IETF RFC 2898, <http://www.ietf.org/rfc/rfc2898.txt>.  Note that all of the PKCS#5 definition of PBKDF2 assumes that actual lengths (as binary data) are involved and the lengths are available as far as PBKDF2 is concerned.

The relevant part of the HMAC specification (i.e., IETF RFC 2104, <http://www.ietf.org/rfc/rfc2104.txt>) is in the first paragraph of section 2, where passwords longer than the block size of the PRF are pre-hashed by the hash function of the PRF (at which time their original length is handled according to whatever the hash-required padding/finalization is).

With regard to the 0-padding of the key to the block size, the concern is correct (and I was presumptive in thinking that was not a problem).

The 0-padding is preliminary to the xor with opad (or ipad) as defined in the remainder of section 2.  In this case, it is true that adding 0 bytes to the end of a password that ends up still less than blocksize in length will have the same PBKDF2 result.
 
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.

Another nice quality of such streamlining is that the original (pre-hashed) key can be "released" where there is an arrangement for that.  (In C Language interfaces, the by-value pointer passed in can be NULL-ed, at that point, for what it's worth.  There's more possible depending on customized interfaces to the implementation.)  

Also, the H(K XOR opad || ...) and H(K XOR ipad || ...) first-block gobbles can be precomputed and reused in every iteration.  I would certainly expect an opportunistic but determined adversary having a purloined PBKDF2 output to have already accomplished at least that much.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@....org] 
Sent: Friday, March 7, 2014 09:14
To: discussions@...sword-hashing.net
Subject: RE: [PHC] Are password trailing 0's a problem?

Bill,

I think you have a defective implementation of PBKDF2.

For long passwords, there is supposed to be a pre-hash prior to the normal PBKDF2 PRF setup and cycling.  It certainly allows some timing determination, but it should be very gross (in terms of hash blocks, not password bytes, and the cycle count should swamp even that).  I do think using PBKDF2 with c == 1 is a strange act.

Also, it seems that padding of the key is being done incorrectly if adding 0 bytes to the key makes no difference.  Could it be that the PBKDF2 implementation is assuming that the key is a C language character string and length is being determined by the occurrence of the first null byte?  How is key length communicated to the PBKDF2 implementation?  PBKDF2 should be implemented to accept any sequence of binary octets of specified length for key values.

[ ... ]
 
-----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.

Another concern about PBKDF2 is that it calls HMAC_Init with the
password, and if for some reason the password is > 64 bytes, it is
passed to the PRF directly, resulting in a very early call with
runtime proportional to the password length.  Of course, the length is
> 64, which is insanely long, so perhaps that's a secure enough
password, but an attacker might gain useful information such as
whether the long-password guy has logged in lately.

[ ... ]

Powered by blists - more mailing lists