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
