3

I'm deriving keys from a user-supplied passphrase for symmetric encryption using AES-256 in CBC mode with a HMAC for authenticity/integrity.

My key derivation function currently looks like this:

enter image description here

Please note that scrypt could just as easily be subbed out for PBKDF2 or bcrypt, that remains to be seen.

I have a couple questions:

  1. Does input truncation using SHA-256 expose any potential weaknesses?
    • My reasoning for doing it in the first place is because many algorithms like bcrypt only accept a limited password input size. (bcrypt seems to accept up to 55 or 72 characters, not sure on the source of this)
    • Would it be better to prefer a hash method with a longer output, ie SHA-512?
  2. When generating the HMAC authentication and encryption keys, would I benefit at all from using SHA-512?
    • AES-256 IIRC needs 256-bit keys, so if I either used AES-192 or used SHA-512, how would I go about fixing the discrepancy in required size?
e-sushi
  • 17,891
  • 12
  • 83
  • 229
Naftuli Kay
  • 967
  • 1
  • 10
  • 14

1 Answers1

4

Does input truncation using SHA-256 expose any potential weaknesses?

No, hashing the passphrase with SHA-256 will be no stronger or weaker than feeding it in directly. If you go with Scrypt (which I would recommend you do), there are no restrictions on the size of the passphrase... and Scrypt consumes it internally with one round of PBKDF2-HMAC-SHA256 anyway.

When generating the HMAC authentication and encryption keys, would I benefit at all from using SHA-512?

No, you wouldn't. In fact, this step is unnecessary. Just use the output of Scrypt directly... randomBytes = Scrypt(passphrase); encKey = randomBytes[0, 31]; authKey = randomBytes[32, 63]

hunter
  • 3,965
  • 6
  • 28
  • 42
  • " Just use the output of Scrypt " only applies if it is outputting 512 bits of data – Richie Frame May 23 '14 at 19:05
  • @RichieFrame - of course... it's simply a matter of requesting 512 bits of output. – hunter May 23 '14 at 19:27
  • Scrypt uses SHA256 as part of its output function, one could replace that with SHA512 to natively output 512 bits instead of using PBKDF2-SHA256 looped – Richie Frame May 23 '14 at 19:54
  • @hunter, scrypt calls PBKDF2 with a large output size, meaning multiple SHA256-HMAC invocations are done in parallel with the password and differing block numbers. Wouldn't this mean that scrypt can theoretically use more of the password than the 256 bits that SHA-256 preprocessing would truncate it to? Edit: Of course, if you only use 256 bits of the output (like the OP), that's moot... – otus May 23 '14 at 20:08
  • @otus - theoretically, yes, if the original passphrase contains more than 256 bits of entropy (around 40 characters), which is unlikely. – hunter May 23 '14 at 20:37
  • What advantages are gained by just splitting the output from scrypt in key derivation? Why is not using a HMAC as a PRNG a better option? – Naftuli Kay May 23 '14 at 21:13
  • Splitting the Scrypt output is simpler, and thus less error-prone. Each bit of Scrypt output is effectively independent of every other bit - it's perfectly suitable as key material. Using HMAC on the output is not a better option because it's redundant (it wouldn't hurt, though). – hunter May 23 '14 at 21:42
  • 1
    Although the bits are independent, I think there is something to be said about using a separate KDF to retrieve the separate keys. I think that is actually more elegant and clear than simply using following output. It is also less error prone; if you would replace scrypt by PBKDF2, you would for instance get in trouble. I would however go for a well defined KBKDF such as HKDF instead of inventing your own. – Maarten Bodewes May 27 '14 at 00:00