3 ms·

I recommend the scrypt command line utility [1] instead of openssl. Openssl use md5 as a key derivation function [2], and cost of recovering a reasonable length

I recommend the scrypt command line utility [1] instead of openssl. Openssl use md5 as a key derivation function [2], and cost of recovering a reasonable length, randomly generated password is surprisingly low [3]. The costs in the presentation are from 2009, and I can only imagine how they've dropped thanks to a few years of bitcoin-driven gpu/hardware developments. If you trust your code host, e.g. github or bitbucket, this isn't a concern, but neither are plaintext passwords in version control. If you're using a very long, randomly generated password, you're safe as well. The disadvantage is that you'll need to compile scrypt from source. [1] http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html [2] slide 20: http://www.tarsnap.com/scrypt/scrypt-slides.pdf http://www.tarsnap.com/scrypt/scrypt-slides.pdf [3] slide 19: http://www.tarsnap.com/scrypt/scrypt-slides.pdf http://www.tarsnap.com/scrypt/scrypt-slides.pdf

mixmastamyk 14y ago
Looks to be in recent Ubuntus, is it not the same package? http://packages.ubuntu.com/search?keywords=scrypt
- moonboots 14y ago
  That package is it. It's in the universe repo, which is disabled by default (I think), so I didn't want to claim scrypt was as convenient as openssl.
helper 14y ago
You seem to be confused. scrypt is a key derivation function. This blog is suggesting you use openssl (using cast5-cbc cipher) to encrypt/decrypt text that happens to contain passwords. The two actions (key derivation vs encryption/decryption) are orthogonal. Replacing an encryption algorithm with a key derivation function doesn't make sense.
- moonboots 14y ago
  The scrypt command line utility uses the scrypt kdf to generate a 256 bit key for aes. Both kdf and cipher are used during single file encryption with openssl and the scrypt command line utility. Openssl implicitly uses a md5 as a kdf during encryption [1.1][1.2]. Cast5 requires a 128bit key, and the kdf helps stretch the user's password to fit this key requirement. I can understand the confusion, as scrypt is typically referenced in kdf discussions. It's actually somewhat difficult to extract the kdf functionality from the scrypt source code because the code is geared towards single file encryption. See this post for a confused q&a with scrypt's author [2]. Wrappers around scrypt like this python package[3] have made the "mistake" of using the entire encryption pipeline when they just wanted the kdf. Using scrypt in this manner should still be safe, but it will waste some cpu cycles on aes. [1.1] http://www.openssl.org/docs/apps/enc.html http://www.openssl.org/docs/apps/enc.html [1.2] http://www.openssl.org/docs/crypto/EVP_BytesToKey.html http://www.openssl.org/docs/crypto/EVP_BytesToKey.html [2] https://news.ycombinator.com/item?id=1350392 https://news.ycombinator.com/item?id=1350392 [3] http://pypi.python.org/pypi/scrypt/ http://pypi.python.org/pypi/scrypt/
  - helper 14y ago
    I see. In that case I take back everything I said.
- moe 14y ago
  I wonder why he chose Cast5 instead of AES. It probably doesn't matter either way, but when you deviate from standard best practices in crypto you should at least explain why you do it. (my best guess would be that the code predates the invention of AES?)

mixmastamyk 14y ago

Looks to be in recent Ubuntus, is it not the same package? http://packages.ubuntu.com/search?keywords=scrypt

moonboots 14y ago
That package is it. It's in the universe repo, which is disabled by default (I think), so I didn't want to claim scrypt was as convenient as openssl.

helper 14y ago

You seem to be confused. scrypt is a key derivation function. This blog is suggesting you use openssl (using cast5-cbc cipher) to encrypt/decrypt text that happens to contain passwords. The two actions (key derivation vs encryption/decryption) are orthogonal. Replacing an encryption algorithm with a key derivation function doesn't make sense.

moonboots 14y ago
The scrypt command line utility uses the scrypt kdf to generate a 256 bit key for aes. Both kdf and cipher are used during single file encryption with openssl and the scrypt command line utility. Openssl implicitly uses a md5 as a kdf during encryption [1.1][1.2]. Cast5 requires a 128bit key, and the kdf helps stretch the user's password to fit this key requirement. I can understand the confusion, as scrypt is typically referenced in kdf discussions. It's actually somewhat difficult to extract the kdf functionality from the scrypt source code because the code is geared towards single file encryption. See this post for a confused q&a with scrypt's author [2]. Wrappers around scrypt like this python package[3] have made the "mistake" of using the entire encryption pipeline when they just wanted the kdf. Using scrypt in this manner should still be safe, but it will waste some cpu cycles on aes. [1.1] http://www.openssl.org/docs/apps/enc.html http://www.openssl.org/docs/apps/enc.html [1.2] http://www.openssl.org/docs/crypto/EVP_BytesToKey.html http://www.openssl.org/docs/crypto/EVP_BytesToKey.html [2] https://news.ycombinator.com/item?id=1350392 https://news.ycombinator.com/item?id=1350392 [3] http://pypi.python.org/pypi/scrypt/ http://pypi.python.org/pypi/scrypt/
- helper 14y ago
  I see. In that case I take back everything I said.
moe 14y ago
I wonder why he chose Cast5 instead of AES. It probably doesn't matter either way, but when you deviate from standard best practices in crypto you should at least explain why you do it. (my best guess would be that the code predates the invention of AES?)