# is it safe to leak some information about scrypt result?

I am encrypting a file via AES-CBC and am using scrypt to extract a key from a user-provided password. The IV is public and is stored with the encrypted file.

Is it safe to generate my IV (public) and key (private) together using scrypt (e.g. set dklen=64 then use scrypt[0...31] for key and scrypt[32...63] for IV), or will I be leaking some kind of state information?

## 1 Answer

That should be fine, as long as you never reuse it for any other purpose. (E.g., if you want to encrypt another file with the same password, generate a fresh salt.)

But there's a simpler approach: Use AES256-CTR with nonce 0 and forget about AES256-CBC altogether. No more worry about unaligned message lengths or padding, how to choose initialization vectors, etc.

I encourage you to consider authentication too. For example, instead of the unauthenticated AES256-CBC, you could use AES256-GCM, or AES256-CTR with HMAC-SHA256 in encrypt-then-MAC composition. In fact, maybe you would be better off just using the scrypt(1) utility, which has a simple format.

• Thanks. I'm also going to be implementing CTR mode and some others, it's more of a learning project for myself than anything. May 3 '18 at 18:46
• Regarding the second paragraph: what's suggested is common an practically safe; but in AES-CTR with single-use key, using fixed nonce rather than random makes possible a multi-target attack assuming known (e.g.) first block of $n$ plaintexts: we try keys (e.g. sequentially), encipher the fixed nonce, and search the result among the $n$ known first block of keystream. Compared to random nonce, $n-1$ AES encryptions get replaced by a search among $n$ values.
– fgrieu
May 3 '18 at 18:47
• @fgrieu This is not a problem if you use AES-256 as the original questioner seems to be doing, judging by the use of the first 32 bytes of scrypt output for an AES key. May 3 '18 at 21:43