Comments on: Secure Password Storage Official blog of Red Sweater Software Sat, 07 Jul 2012 16:41:17 +0000 hourly 1 By: David Leppik Thu, 29 Mar 2012 20:53:48 +0000 It’s worth noting that the original article doesn’t say bcrypt is bad, simply that there are better algorithms out there. The most important thing is to not use insecure hashes that look good but are really easy to crack– which is the first thing that naive programmers try. (If you’re going to use an md5 hash, why not go all the way and use rot-13? At least that way you’re not fooling yourself.)

Quoth the source:

“If you’re already using bcrypt, relax, you’re fine, probably. However, if you’re looking for a key derivation function (or in bcrypt’s case, password encryption function) for a new project, bcrypt is probably not the best one you can pick. In fact, there are two algorithms which are each better in a different way than bcrypt, and also widely available across many platforms.”

By: Allan Odgaard Tue, 27 Mar 2012 04:42:06 +0000 If you change “private key” to “secret key” there should be no terminology confusion.

By: Daniel Jalkut Thu, 22 Mar 2012 13:46:35 +0000 I decided to update the example back to AES to better support the symmetric encryption being discussed throughout the post. Hope I didn’t screw anything up :)

By: Daniel Jalkut Thu, 22 Mar 2012 13:19:24 +0000 Allan – ah, thanks for that. I guess it makes sense that you only need a derived key when there needs to be a link to a simpler (i.e. passphrase) key.

By: Allan Odgaard Thu, 22 Mar 2012 10:11:17 +0000 In the case of RSA the (private) key is not derived from a typed password; it is read from disk, e.g. `~/.ssh/id_rsa` or the keychain (My Certificates).

Derived keys are only for symmetric ciphers, though of course a private key itself is often encrypted with a symmetric cipher, thus requiring a “simple” password to use it.

By: Daniel Jalkut Tue, 20 Mar 2012 21:31:46 +0000 Jeffrey & Dan – thanks for the great additional clarifications. It’s opening my eyes ever further.

By: Dan Grassi Tue, 20 Mar 2012 21:28:39 +0000 Here is a link to an image that provided security information for various key sized for both symmetric (DES, AES, etc) and asymmetric (RSA).

Generally it is believed that 128-bit AES is sufficient for the foreseeable future and the equivalent for RSA it 3072-bits so the best is to go to 4096-bits.

Triple-DES can be either 112-bit or 168-bit with the 112-bit version common in electronic funds transfers. It is not bad if one stays away from a few weak keys (which one would expect of Apple.)

Typically data is encrypted with symmetric encryption and keys are encrypted with asymmetric encryption.

PBKDF2 is used for key derivation. Handling keys is a hard cryptography issue.

By: Jeffrey Goldberg Tue, 20 Mar 2012 21:22:58 +0000 [Disclosure I am Chief Defender Against the Dark Arts at AgileBits, the makers of 1Password.]

Thanks for bringing the importance of key derivation functions to more people’s attention. I’d like to clarify a couple of things that you do state correctly, but may not have come across all that clearly to readers.

Key derivation functions serve two purposes. First they “stretch” a key. For example, AES uses a 128 bit key in most cases. Even a very good master password that someone comes up with is not going to be 128bits strong. So the first function of a key derivation is to turn a “stretch” a string of characters out to 128 bits (or whatever is needed).

The second thing is that they are designed to slow things down. The process of getting from the password that people type in to the key should not happen too swiftly. This is to help slow down automated crackers.

There is one other thing to note, an additional complication. For somethings (like a typical 1024 bit RSA key, or indeed the AES key that is used to encrypt 1Password data) are actually picked at random when the key is first set up. This key is then encrypted using something derived (through a key derivation function) from the user’s password. So your password (via PBKDF2) gets turned into a derived key, and this derived key is used to decrypt your actual, random, key.

What this means is that people who have the same password, still don’t have the same key. It also means that the bulk of the encryption is performed with a really truly random key.

Apple’s OS X keychain design has improved since the time we (at AgileBits) moved away from using it, and people should be very confortable storing credentials in it, as long as they understand that under default settings that keychain is protected by the users OS X login password.



Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits

By: Daniel Jalkut Tue, 20 Mar 2012 17:57:47 +0000 Thanks, Jean-Daniel. You caught my ignorance very quickly ;) I’ve updated the example to cite RSA as the example algorithm and 1024-bits as the key size. Is that more believable?

By: Jean-Daniel Tue, 20 Mar 2012 17:50:26 +0000 “An encryption technique like AES use a huge (e.g. 128 bits), extremely difficult to guess private key to decrypt data that was encrypted by another huge, but public key.”

Arrggghh, AES is a symmetric algorithm. It does not use a public and a private key, but a single shared secret key.

Moreover, 128 bits is very small for an asymmetric key, and can be guess easily, that’s why we use 1024 or 2048 bits for such key pair.