Re: scrypt encryption utility - choice of IV/nonce (and command line interface)

[Colin Percival <cperciva@tarsnap.com>]

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.

> 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).

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.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid