Using scrypt to generate key + IV/nonce together

Question

Is there any security issue in using scrypt for Key + IV/nonce generation? In other words, can I safely use only a salt for scrypt and derive the nonce along with the key?

For example:

I have data I want to encrypt using password and AES in EAX mode. I want to use scrypt key derivation function to make a key from entered password. So I will need a salt for scrypt and a nonce for EAX. Both values need to be stored somewhere and it seems to be quite redundant. So instead I generate 384 bits of output using scrypt and use the first 256 bits as key and last 128 bits as nonce for EAX.

Answer 1

Yes, this is secure, even though scrypt uses PBKDF2 inside. PBKDF2 has the issue that it the work factor is required $n$ times where $n$ is the number hash outputs concatenated to create the final PBKDF2 output. That means that if you can check the validity of PBKDF2 using only the initial bits (in your case used for the key if the hash was SHA-256, for instance) that you have less of an advantage over an attacker. Basically your initial advantage is divided by $n$.

In scrypt however the final output calculated using a single iteration of PBKDF2, basically turning PBKDF2 into a KBKDF (key based key derivation function) where the calculation of the salt is used as the work factor. As the output size only relies on this single iteration the attacker would not gain an advantage.

---

That all said, it may make more sense to use a true KBKDF - such as HKDF-expand - to calculate two separate components (key and nonce) from the output of scrypt. In that case the OtherInfo part of the KBKDF (the derivation data) can be just an ASCII representation of the string "key" and "nonce".

So say that p = 1 and MFLen = hLen = dkLen = 32 bytes (output length of SHA-256), then perform:

m = scrypt(Passphrase, Salt, N)
k = HKDF-expand(m, "key", 32)
nonce = HKDF-expand(m, "nonce", 16)

Note that a KBKDF such as HKDF does not contain a work factor; i.e. all the time is still spend in the call to scrypt, not in the calls to HKDF.