Isn't "NIST approving" the algorithm a blatant red flag?

]]>95 * 95 * 95 * 95 * 95 * 95 * 95 * 95 = 95^8 = 6,634,204,312,890,625 passwords

I understand that to be "keyspace," the set of all possible permutations at a given length: 95^8. Whereas "search space" would be the total number of all possible permutations up to and including the given length: 95^1 + 95^2 + 95^3 + 95^4 + 95^5 + 95^6 + 95^7 + 95^8.

Please forgive my ignorance, and correct my understanding if I'm wrong.

]]>1. Large keyspace (keysize).

e.g. 128-bit or 256-bit.

2. The encryption should be able to actually provide such keyspace, shortcuts are not allowed.

e.g. AES (best cryptanalysis reduced 128-bit AES to 126-bit but still good enough), or TwoFish

3. The chosen encryption key should have as much entropy as the keysize.

e.g. 123456 for 256-bit AES is almost 0-bit encryption, not a 256-bit encryption at all.

However, in the real world, a passphrase instead of a random key is often used (e.g. full disk encryption), because humans are not able to memorize long random bytes.

So, in my understanding, no matter what type of key-derivation algorithm, or hash algorithm you use, to slowdown the brute-force attack, even if you can make it impossible, a 128-bit full disk encryption, protected by a passphrase with 70-bit of entropy, is ultimately still 70-bit encryption, am I correct?

]]>Aaron, I think I find a ,mistake (propably during copy&paste) ;

"The SHA1 of “pthree.org” is “4f019154eaefe82946d833f1b05aa1968f1f202a”"

It actually is bea133441136e7a7c992aa2e961002c170e54c93 .

This is the same value as you stated after running sha 1000 times, that's why I decided to check it. 🙂

]]>I usually use two or three common words linked with dots or asterisk as passwords. Those simple words combined create very long strings.

Your explanation here gives me one more reason to continue using them.

]]>Regarding key stretching, that is precisely what it is. I avoided using the term, because I wanted people to understand exactly what was happening. For the newcomer, "key stretching" seems like you're physically lengthening the password, which of course you aren't. Rotating the password, however, makes a bit more intuitive sense. However, there are some subtle differences- key stretching can include concatenating the result with the original password at each SHA1. It could also involve concatenating a salt with that operation as well. Here, with the term "rotating", I'm specifically referring to using the previous output as the new input.

]]>Slower algorithms, such as Blowfish and MD5, will hinder brute force attacks

I don't think I've heard anyone describe MD5 as slow in the general sense.

A ran a simple PHP script to confirm this, I was able to do roughly 1,000,000 md5 runs in 0.5 seconds on my Macbook Air. Using Blowfish with a cost of 04 (the lowest value supported) I was only able to do roughly 450 runs in 0.5 seconds.

Raising the cost to 08, which is the default for things like phpass and WordPress slowed things down dramatically. I was only able to do roughly 30 runs in 0.5 seconds.

Rotating the password thousands of times

Is there a difference between what you are describing and key stretching?

The numbers you described were specifically for NTLM. It would be interesting to see how that compares to other algorithms.

]]>