On 11/23/12 13:16, Derek (Tarsnap) wrote: > I'd like to understand why a constant (0) was chosen for the nonce for AES CTR > mode. I understand that since the key we're using has an extremely low chance > of ever being used twice (due to pre-salting), and that the output of AES CTR > is > key-dependant, it would not really be a problem.
Right, there's a 256-bit salt used in computing the key, so even if you generate 2^64 messages, you have a probability of only 2^(-128) of having the AES key repeat (even if you're using the same passphrase); and repeating the same nonce value is harmless if you're using different keys. > 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. > Any interest in a patch for this? Additional complexity and a change in file format without any improvement in the security? No thanks. ;-) > 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. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
