0
$\begingroup$

I'm using PBKDF2 to generate a 512 bit key. My question is language agnostic, but for the sake of demonstration, I'm using CryptoJS, which defaults to using SHA1, but can be overridden like so:

var hasher = CryptoJS.algo.SHA512;
var output = CryptoJS.PBKDF2(input, salt, { keySize: 512/32, hasher: hasher });

The output string I get for input = "hello" and salt = "world" is

d75f41243491533cc1ecc178d4bae14e7c3384dd2d94067c333594ebf3aa4cce4cd6670e4a3233af4237425617b3b21ec7d586a9478c0749cc40a778500821c8

However, upon inspection of the output object, it tells me that the output has:

  • 64 sigbytes
  • 16 words

If I run the function without specifying a hasher, which means I would be demanding a 512 bit output from SHA1, like so:

var output = CryptoJS.PBKDF2(input, salt, { keySize: 512/32 });

Then I get 64 sigbytes and 20 words, and a result of:

798ef2617367d80daeacf8b457af7903eebf6d1f384c9fed762b14186036e912b37026c14ae315da0a9782aa773bdafcd9cd259e95381ac9ab26d026fe6a3375

My question is, what is the right number of words for a 512 bit function? Why does the second one result in more words?

$\endgroup$
  • $\begingroup$ What do you mean by a word? If a word is 4 bytes, then isn't 64 bytes 16 words??? $\endgroup$ – poncho Nov 22 '16 at 4:50
  • $\begingroup$ Yes if that's the case then that seems correct. But why would I get more words out of the second one? $\endgroup$ – Snowman Nov 22 '16 at 5:50
1
$\begingroup$

PBKDF2's output is defined by the underlying functions which produce 160 bits (20 bytes) at a time. Let me explain using RFC 2898 which defines PBKDF2.

OK, so lets start with the output of PBKDF2 and work backwards:

Concatenate the blocks and extract the first dkLen octets to produce a derived key DK:

DK = T_1 || T_2 ||  ...  || T_l<0..r-1>

Now the values of T_x are defined as output of function F:

F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c

and U_i is again the output of the PRF. The PRF is the HMAC value and the HMAC output size is the same size as the underlying hash function.

OK, so the output size of the of the T_x values is consists of 4 blocks of length hLen (4 times 160 bits for SHA-1, making 640 bits or 80 bytes), the hash length. If there were 3 blocks then the output would be 60 bytes and you'd have 4 bytes too few.

Each hash consists of five 32 bit (4 byte) words, to make 160 bits. The size of a word in this case is determined by SHA-1 which is defined using 32 bit calculations. The same 32 bit word is used for the other calculations such as XOR. So in total the number of words in the output is 80 / 4 = 20.

So what you have there is the value of the output before the leftmost 64 bytes are taken. In general cryptographic functions should convert the output to bytes/octets of the correct size. But that has clearly not happened yet.


There is no problem for PBKDF2 with SHA-512 for the simple reason that you ask for exactly 512 bits, the output size of SHA-512 (i.e. four 64 bit words, as SHA-512 is defined using 64 bit operations).

Note that it could still return eight 32-bit words if the implementation uses 32 bit words instead of 64.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Added the last sentence about the implementation of SHA-512 / PBKDF2-SHA512 ... what's a word worth? $\endgroup$ – Maarten Bodewes Nov 23 '16 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.