2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ yes. AFAICT this is common practice if a KDF (like HKDF, PBKDF2, scrypt) is used. $\endgroup$ – SEJPM Aug 20 '15 at 15:55
  • $\begingroup$ @SEJPM Yes, but that could be mainly because nobody seems to know about KBKDF's :) It should of course also be possible to do this with a good PBKDF without giving an advantage to an attacker. At least HKDF-expand has been designed for this purpose. $\endgroup$ – Maarten Bodewes Aug 20 '15 at 16:55
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ The latter would be mainly an option if a good KBKDF is available in your crypto library. $\endgroup$ – Maarten Bodewes Aug 20 '15 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.