4 ms·
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.
by 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.
- cperciva 13y agoTo take a concrete example of encryption using a key derived from a passphrase: SSH keys. OpenSSH uses MD5 as a key derivation function, so if someone steals a passphrased SSH key file you'd better hope that the passphrase is very strong.
- keeperofdakeys 13y agoUsing a KDF such as scrypt for that example does make a lot of sense, and after considering some others, I must admit, makes a lot of sense for most circumstances. I also had a quick look at the tarsnap source code, and I see you do exactly that for the passphrased keyfile.
- cperciva 13y agoYes -- in fact, that's why I invented scrypt, because I was adding passphrase encryption to tarsnap key files and wanted to do it as securely as possible.
- croikle 13y agoNote that it's possible to convert your keys to use PBKDF2: http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html http://martin.kleppmann.com/2013/05/24/improving-security-of...