On 11/23/12 19:52, Derek (Tarsnap) wrote:
On 11/23/2012 06:53 PM, Colin Percival wrote:
Would there be any harm in using say, the first 8 bytes of the header HMAC, or
the last 8-bytes of the derived key, instead of a constant?
Unnecessary complexity. And if you really wanted a random nonce value, you'd be
better off taking it as additional output from the scrypt KDF.
Perfect answer.
re: 'taking it as additional output', that's same as taking the the last 8 bytes
of the dk like I mentioned, no?
Not exactly. Modern KDFs, like PBKDF2 and scrypt, let you specify how many
bytes of output you want them to produce; in the encryption utility I take
64 bytes of output from scrypt and split it into a 256-bit encryption key and
a 256-bit HMAC key, but I could easily ask scrypt for 72 bytes instead.
You marginally reduce the chance of a collision of the output of the KDF (using
320-bits of it in the AES calculation instead of 256).
You are now more likely to experience a collision on the input, instead of them
being approximately equal (assuming perfect distribution of the input salt, and
the truncated KDF output).
You also make it more expensive to brute force the AES key + IV (Although we can
talk about the heat death of the universe and all that, trying to brute force
256-bit encryption. I'd take 320-bit equivalent if it's free).
I see what you're getting at; but nobody is ever going to brute force search a
256-bit keyspace, so any attack would come in other ways -- attacking the
passphrase, side channel information leaks, attacking the humans, etc.