4 ms·

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 happ

by 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?)

by helper 14y ago

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?)