6 ms·

Probably the best KDF you'll get right now is scrypt[1]. NaCl did not see common adoption because until a relatively recent distribution called Sodium[2], it wa

by drostie 13y ago

Probably the best KDF you'll get right now is scrypt[1]. NaCl did not see common adoption because until a relatively recent distribution called Sodium[2], it was not portable. And I mean really, not portable. Like, just to give an example, suppose you want to use NaCl in Node.js, which is pretty good about accepting C/C++ modules. You have two options today: one doesn't work on a 64-bit system[3] and one isn't C, it's JS which was transpiled with Emscripten[4]. I mean, don't get me wrong: the fact that we can now do this in pure JS via Emscripten is amazing, but yeah, NaCl was not universally buildable and therefore was not reliably deployable, and nobody really wanted to fix it until Sodium came along. [1] https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html [2] https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium [3] https://github.com/thejh/node-nacl https://github.com/thejh/node-nacl [4] https://github.com/tonyg/js-nacl https://github.com/tonyg/js-nacl

tptacek 13y ago
scrypt is great if you want to store passwords, but not really helpful in other contexts. Nacl is a complete cryptosystem; think of it as a stronger, more modern, library-ized version of GPG. Don't use a JS translation of Nacl. Nacl goes to pains to ensure that it doesn't expose side channels; no Javascript implementation can make the claims Nacl makes.
- jiggy2011 13y ago
  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.
- cperciva 13y ago
  scrypt is great if you want to store passwords, but not really helpful in other contexts I'd say that scrypt is most useful when generating derived keys for file encryption. For login passwords you probably want a fairly low work factor (say, 0.1 seconds), both to make logins responsive and to make it harder for an attacker to use login attempts to DoS you; but for file encryption you can easily spend 5 seconds or more.
  - keeperofdakeys 13y ago
    Using a KDF with a decent encryption algorithm (ie. AES) doesn't really help much, (it doesn't make it worse, either). Considering you'll be using something like AES-CBC, you will already have a salt/IV as part of the encryption process, and you are safe against people finding your key from multiple ciphertexts. So there are no real problems that adding scrypt solves, besides "making it slower".
    - cperciva 13y ago
      for P in password candidates do: compute K = KDF(P, salt); M_0 = decrypt(block #0 of cyphertext, K, IV); if M_0 looks like plaintext: store P for future analysis fi od Encryption using a passphrase needs a good KDF just as much as login password hashing does.
      - keeperofdakeys 13y ago
        I may have been a bit rash to say, "there are no problems that adding scrypt solves," but whether you need a KDF for encryption is more of a practical problem. There are many circumstances where it makes sense, but I'd consider that a part of your password policy. In general, encryption is secure by itself, and I'd avoid adding unneeded steps. As for password hashing, that is a very different application than deriving a key for encryption. You are storing the result (usually in a database), and in the case there is a leak, hoping that no one can brute-force the passwords. This is when you start the process of changing salts and work values (in the case of scrypt), and getting everyone to change their password. Using a KDF in this case makes a lot of sense.
- iuguy 13y ago
  > Don't use a JS translation of Nacl. Nacl goes to pains to ensure that it doesn't expose side channels; no Javascript implementation can make the claims Nacl makes. What specifically are the side channels you see that Javascript exposes?
  - tlb 13y ago
    Lack of evidence for side channels is not good enough. You deserve an encryption system that's carefully constructed to prevent all known forms of leakage. The usual side channel is timing. Some numeric operations take longer than others depending on the key, and an adversary can measure these to narrow down possible keys: https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack Javascript engines have complicated numeric type conversion rules, together with single-entry type caches that seem very likely to leak.
    - iuguy 13y ago
      > Lack of evidence for side channels is not good enough. You deserve an encryption system that's carefully constructed to prevent all known forms of leakage. While I agree that absence of evidence is not evidence of absence I have to take you up on that second statement. I'd say you deserve an encryption that's carefully constructed to provide appropriate protection against a threat model matching the use case. A case in point would be MD5. MD5 is vulnerable to collisions, does that mean that we should use MD5 for passwords? Of course not but because of moore's law and scrypt, not because of collisions. Should we use MD5 for hashing content? For anything forensic, no. For situations where collisions aren't important, perhaps yes. Many software crypto systems are susceptible to direct leakage through RAM, that doesn't mean that we shouldn't use them.
      - tptacek 13y ago
        Be aware that we don't know how bad browser side channels are going to be. People were surprised when Boneh and his team showed RSA key extraction over an IP network using just timing a decade or so ago; people will be surprised when someone pulls a key out of a browser by having them visit a spoofed site, too. Why assume the risk?

by drostie 13y ago

tptacek 13y ago

scrypt is great if you want to store passwords, but not really helpful in other contexts. Nacl is a complete cryptosystem; think of it as a stronger, more modern, library-ized version of GPG. Don't use a JS translation of Nacl. Nacl goes to pains to ensure that it doesn't expose side channels; no Javascript implementation can make the claims Nacl makes.

jiggy2011 13y ago
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.
cperciva 13y ago
scrypt is great if you want to store passwords, but not really helpful in other contexts I'd say that scrypt is most useful when generating derived keys for file encryption. For login passwords you probably want a fairly low work factor (say, 0.1 seconds), both to make logins responsive and to make it harder for an attacker to use login attempts to DoS you; but for file encryption you can easily spend 5 seconds or more.
- keeperofdakeys 13y ago
  Using a KDF with a decent encryption algorithm (ie. AES) doesn't really help much, (it doesn't make it worse, either). Considering you'll be using something like AES-CBC, you will already have a salt/IV as part of the encryption process, and you are safe against people finding your key from multiple ciphertexts. So there are no real problems that adding scrypt solves, besides "making it slower".
  - cperciva 13y ago
    for P in password candidates do: compute K = KDF(P, salt); M_0 = decrypt(block #0 of cyphertext, K, IV); if M_0 looks like plaintext: store P for future analysis fi od Encryption using a passphrase needs a good KDF just as much as login password hashing does.
    - keeperofdakeys 13y ago
      I may have been a bit rash to say, "there are no problems that adding scrypt solves," but whether you need a KDF for encryption is more of a practical problem. There are many circumstances where it makes sense, but I'd consider that a part of your password policy. In general, encryption is secure by itself, and I'd avoid adding unneeded steps. As for password hashing, that is a very different application than deriving a key for encryption. You are storing the result (usually in a database), and in the case there is a leak, hoping that no one can brute-force the passwords. This is when you start the process of changing salts and work values (in the case of scrypt), and getting everyone to change their password. Using a KDF in this case makes a lot of sense.
iuguy 13y ago
> Don't use a JS translation of Nacl. Nacl goes to pains to ensure that it doesn't expose side channels; no Javascript implementation can make the claims Nacl makes. What specifically are the side channels you see that Javascript exposes?
- tlb 13y ago
  Lack of evidence for side channels is not good enough. You deserve an encryption system that's carefully constructed to prevent all known forms of leakage. The usual side channel is timing. Some numeric operations take longer than others depending on the key, and an adversary can measure these to narrow down possible keys: https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack Javascript engines have complicated numeric type conversion rules, together with single-entry type caches that seem very likely to leak.
  - iuguy 13y ago
    > Lack of evidence for side channels is not good enough. You deserve an encryption system that's carefully constructed to prevent all known forms of leakage. While I agree that absence of evidence is not evidence of absence I have to take you up on that second statement. I'd say you deserve an encryption that's carefully constructed to provide appropriate protection against a threat model matching the use case. A case in point would be MD5. MD5 is vulnerable to collisions, does that mean that we should use MD5 for passwords? Of course not but because of moore's law and scrypt, not because of collisions. Should we use MD5 for hashing content? For anything forensic, no. For situations where collisions aren't important, perhaps yes. Many software crypto systems are susceptible to direct leakage through RAM, that doesn't mean that we shouldn't use them.
    - tptacek 13y ago
      Be aware that we don't know how bad browser side channels are going to be. People were surprised when Boneh and his team showed RSA key extraction over an IP network using just timing a decade or so ago; people will be surprised when someone pulls a key out of a browser by having them visit a spoofed site, too. Why assume the risk?