Found this on password entropy:
If you’re trying to encrypt data using a password, how do you convert the password into a key for symmetric encryption? The easiest way might be to simply convert the password to a byte array, and use this array as your key. However, this is a very bad idea and will lead to an easily cracked system. First of all, for a 256 bit encryption algorithm your passwords would all have to be exactly 8 bytes, or you would end up with not enough bits for the key; or worse, too many bits for the key, meaning that every password that starts with the same eight characters will work to decrypt the data.
In the English language, passwords will probably only contain the characters a-z, A-Z, 0-9, and perhaps some symbols. This means that only 70-75 of the possible 256 bit combinations for each byte will be used. In addition, not every symbol will be used with even frequency. Various estimates for the entropy in a single byte of an English language password vary from 1.3 to 4 bits. This means that in order to generate a good 256 bit key, you’ll need a password that’s anywhere from 64 to 197 bytes long!
(from http://blogs.msdn.com/shawnfa/archive/2004/04/14/113514.aspx)
This is useful when considering password strength as compared to cryptographic keys.
Just a comment on the problem of converting a password to a cryptographic key. I have some experience with the Entrust Public Key Infrastructure product. It’s a bit more complex in terms of the process of going from a password to a crypto key.
First, you have to realize that Entrust uses something they call an Entrust Profile, which is a file that contains some plaintext data and some encrypted data. In order to use a cryptographic key pair for encrypting or decrypting a symmetric key (which is randomly generated using strictly governed algorithms certified by the government), you have to decrypt the private (or secret) part of the public key pair (also generated in a similar random fashion).
The interesting and relevant part of the process (to this blog post anyway) is that the password you choose is hashed something like 10,000 times, every time it is used to decrypt the profile to access the private key. It makes for a pretty good random distribution of bits witin a fixed hash size. Certainly, not all products go to this extreme to ensure that passwords are not subject to attack due to the problem you describe above.
Entrust does enforce strong passwords with a configurable policy; with more settings than you’ll probably ever need (eg. percent of password that can be repeated in substrings, etc.).
I don’t know if that adds value or not, but at least some of us care!