3 ms·

Couldn't you use the output of scrypt as a key for a symmetric cipher?

by jiggy2011 13y ago

tptacek 13y ago
You could if you were going to design your own cryptosystem, but not doing that is the point of this subthread.
- kragen 13y ago
  Nacl still leaves you with the necessity to manage your keys, whether you're deriving them from passphrases (in which case you should use a KDF, and scrypt should work) or storing them.
  - tptacek 13y ago
    Ok, that's true; if you use the secretbox APIs and aren't using randomized keys, you'd want something like scrypt. You're right.
    - kragen 13y ago
      Even if you're using the non-secretbox APIs like crypto_box.
- tel 13y ago
  At what point aren't you designing your own cryptosystem? Even if you use NaCl you must store your keys, determine when and when not to encrypt, decide how to generate nonces, pick between symmetric and asymmetric ciphers. I understand strongly that you should work with as large a black box as you can afford, but it becomes increasingly grey as you move toward operational stuff over "obvious" crypto stuff.
keeperofdakeys 13y ago
Scrypt is a Key Derivation Function, as well as a password hash, so it has a few uses. If you want to take many parameters, and make a random key, it will work well. If you want to record a secret value (ie. password database), it works incredibly well. If you want to use it on a password for something like AES-CBC, then you probably don't need it, since AES-CBC is already secure. Most encryption algorithms are already designed to take a users key, and apply them in a secure fashion. Unless you aren't using such an algorithm, you should trust the crypto primitives that have already been built for you. Of course, many people will have special use cases, but they should already know what they are.
- sk5t 13y ago
  I really can't recommend skipping a KDF for encryption on the basis that AES-CBC is "already secure." Use of a strong KDF has a direct bearing on the compute time required for an attacker to brute force the key.
  - singlow 13y ago
    I think he means that your AES-CBC should already be doing key derivation from the user supplied password.

Couldn't you use the output of scrypt as a key for a symmetric cipher?

tptacek 13y ago

You could if you were going to design your own cryptosystem, but not doing that is the point of this subthread.

kragen 13y ago
Nacl still leaves you with the necessity to manage your keys, whether you're deriving them from passphrases (in which case you should use a KDF, and scrypt should work) or storing them.
- tptacek 13y ago
  Ok, that's true; if you use the secretbox APIs and aren't using randomized keys, you'd want something like scrypt. You're right.
  - kragen 13y ago
    Even if you're using the non-secretbox APIs like crypto_box.
tel 13y ago
At what point aren't you designing your own cryptosystem? Even if you use NaCl you must store your keys, determine when and when not to encrypt, decide how to generate nonces, pick between symmetric and asymmetric ciphers. I understand strongly that you should work with as large a black box as you can afford, but it becomes increasingly grey as you move toward operational stuff over "obvious" crypto stuff.

keeperofdakeys 13y ago

Scrypt is a Key Derivation Function, as well as a password hash, so it has a few uses. If you want to take many parameters, and make a random key, it will work well. If you want to record a secret value (ie. password database), it works incredibly well. If you want to use it on a password for something like AES-CBC, then you probably don't need it, since AES-CBC is already secure. Most encryption algorithms are already designed to take a users key, and apply them in a secure fashion. Unless you aren't using such an algorithm, you should trust the crypto primitives that have already been built for you. Of course, many people will have special use cases, but they should already know what they are.

sk5t 13y ago
I really can't recommend skipping a KDF for encryption on the basis that AES-CBC is "already secure." Use of a strong KDF has a direct bearing on the compute time required for an attacker to brute force the key.
- singlow 13y ago
  I think he means that your AES-CBC should already be doing key derivation from the user supplied password.