Thank you for your prompt reply. 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.I won't waste any more of your time on this (unless you'd like me to :).
(Please stop reading here, unless you are really bored. I won't feel slighted if I get no response. I'll take it as a sign of my limited understanding on these matters.
re: 'taking it as additional output', that's same as taking the the last 8 bytes of the dk like I mentioned, no?
Your collisions can happen in two places, the input and the output of the KDF.
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).
)
A side note, I'd like to make the utility a little more command-line friendly, especially respect with pipes. Any interest in seeing a patch that has "-" as a valid infile, and perhaps -k keyfile for specifying a file containing the password?These sound fine to me, assuming good quality patches.
I'll do my best! - Derek