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
