Hacker News Reader

Comment by moonboots | Hacker News Reader

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

[2] slide 20: http://www.tarsnap.com/scrypt/scrypt-slides.pdf

[3] slide 19: http://www.tarsnap.com/scrypt/scrypt-slides.pdf

View on HN

Looks to be in recent Ubuntus, is it not the same package?

    http://packages.ubuntu.com/search?keywords=scrypt

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.

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.

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

[1.2] http://www.openssl.org/docs/crypto/EVP_BytesToKey.html

[2] https://news.ycombinator.com/item?id=1350392

[3] http://pypi.python.org/pypi/scrypt/

I see. In that case I take back everything I said.

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

Reply on news.ycombinator.com