I do 20 characters alphanumeric, which gives about 120 bits¹ and is short enough to be bearable to type in by hand (or memorize) if necessary.

I do alphanumeric because I’ve had sites silently corrupt passwords that contain special characters (whereas alphanumeric is basically guaranteed to work) and they only buy you a few more bits regardless.

¹ Which is sufficient. If an attacker can iterate through 10^20 passwords per second (an arbitrary guess at the processing power of the entire world), it will take them a trillion years to go through all of them. My secrets will certainly be uninteresting by then.

I generally do 25. I used to do 99, but found 25 to be right around the threshold of “I can tolerably type this in when necessary”. I don’t think I’ve ever encountered the silent corruption issue, but it’s an interesting issue.

Reminds me of when I recently signed up for some website and it silently truncated my password when I logged in. I went to reset the password, and it just emailed me the password in plaintext. Yikes.

I calculate log((26+26+10)^20)/log(2) = 119.1. Regardless, no, it’s not a big difference.

in 5 years 20 might be too short

The thermodynamic argument for cryptographic strength (briefly, there is a certain thermodynamic minimum amount of energy required to perform any computation and merely counting to 2^256 uses all the energy in the known universe; and the second law of thermodynamics definitely supersedes Moore’s law) indicates that while, eventually, 20 characters may be too short, 40 characters never will be. Going beyond that is pointless and makes the password needlessly difficult to type by hand.

Incidentally, performing this same physics exercise with a 20-character password tells us the bare minimum to count that high on the most efficient computer physically possible would take 31 TJ, which at current electricity prices would cost about $1M. (Practically speaking, of course, the cost to actually crack them on real hardware that actually exists would be dozens of orders of magnitude higher.) I’m comfortable saying that’s well above the value of anything protected by any of my passwords.

The thermodynamic argument for cryptographic strength (briefly, there is a certain thermodynamic minimum amount of energy required to perform any computation and merely counting to 2^256 uses all the energy in the known universe; and the second law of thermodynamics definitely supersedes Moore’s law) indicates that while, eventually, 20 characters may be too short, 40 characters never will be.

Thanks for the link, the thermodynamic argument is not one I’d heard before. Since this link talks about symmetric keys, how did you determine that a 40 character password is long enough for the same thermodynamic guarantee?

Passwords are symmetric keys, approximately. (The harder part is converting asymmetric keys because the difficulty of cracking them, at least for RSA keys, is not proportional to the magnitude of the key but to the square root thereof.) Brute-forcing a password with n bits of entropy is (wild hand-waving) more or less equivalent to brute-forcing a symmetric encryption key with n bits of entropy. A 20 character mixed-case alphanumeric password has about 119 bits of entropy; a 40-character one has about 238 bits.¹ Given that, the same argument follows: the minimum amount of energy for a (more hand-waving) “computation” is 4.4e-16 ergs, so doing one for every 40-character password will use up 2.2e37 TJ of energy, or about five orders of magnitude more than is released by a supernova.²

¹ “Number of bits” is just base-2 log of the size of the password space. There are 26+26+10 = 62 mixed-case alphanumeric characters, so 62^20 = 7.0e35 possible 20-character passwords; log base 2 of that is approximately 119.08.

² Physicists being physicists, there is an evocatively-named unit for this amount of energy: the “foe”, conveniently memorable as ten to the fifty one ergs.Our hypothetical hyper-efficient computer uses about 238 thousand foe going through all the 40-charcter passwords.

You roll 5 six-sided dice to create a 5 digit number. The exact order of the numbers does not matter. Then you compare that number against a wordlist, and based on the roll you pick 6 or more words which you like, string them together in a phrase you can remember.

Well, I know how diceware is supposed to work, so I can figure it out, but otherwise I’d have no idea how I’m supposed to turn five dice into six words. Usually you don’t pick the words you like. That kind of defeats the purpose.

Also, I’ll add that even six times five dice is 6^30, which is nowhere close to your bare minimum of 36^32.

“I am smart enough to do it safely” - you probably are, but I can’t help hearing echoes of the last words spoken by every person about to do something dangerous.

You’re going to have to explain to me how rolling six dice five times provides equivalent entropy to rolling a single die seven and a half thousand times.

Did you mean rolling five dice six times? The math works out differently for rolling six dice five times.

Each roll of the die generates a number in the range 1-6. When you roll a die once, you have 6 possible numbers you could get. When you roll a die twice (once for the tens position and once for the ones position) you have 6*6 (6^2)possible outcomes. Continuing in the same way, for a five digit number, you have 6*6*6*6*6 (6^5)=7776 possible combinations.

Using the same pattern, if I want to generate a list of six five-digit numbers, we raise the length of the list to the number of combinations power. We want 6 five-digit numbers so the base is 6. The number of possible five-digit combinations is what we found above. There are 6^5 possible five-digit numbers. So we end up with 6^(6^5)=6^7776.

I apologize, my snark was unproductive. Your math is wrong and tedu’s is correct. Rolling n dice m times is equivalent to rolling one die n * m times.

The particular mistake you made is

we raise the length of the list to the number of combinations power

this is precisely backwards: we raise the number of combinations to the length of the list. A five digit number has ten possible digits in the first position, ten in the second, etc. for a total of 10*10*10*10*10 or 10^5 possibilities. In the case of our dice, five six-sided dice gives 6^5 = 7776 combinations, six times give 7776^6 = 2.2e23 = 6^30 total possible permutations. (Rolling six dice five times gives (6^6)^5 = 46656^5 = 2.2e23 combinations as well, because (x^y)^z = x^(y*z) and multiplication commutes.)

Also, I’ll add that even six times five dice is 6^30, which is nowhere close to your bare minimum of 36^32.

Isn’t the bare minimum given here for a generated pw while the diceware pw is for the master pw to access the pw database? Being on your own machine adds additional security.

A faster machine can be had on AWS with spot pricing for $12/hour (p2.8xlarge).

The most common characters are (a-z A-Z 0-9) which has 62 values

md5 hashes of all 8-character strings would take: 62^8 / 200,000,000,000 / 60 = 18 minutes.

[EDIT: I am bad at reading units, thanks for pointing that out]
The same machine can do bcrypt with a work-factor of 5 at 100 Khash/sec, but a more likely work-factor is 12.
The work factor is an exponent, so we can divide by 2^(12-5) to get 780 hashes/sec.

bcrypt hashes of all 8-character strings would take: 62^8 / 780 / 60 / 60 / 24 / 365 = 8800 years

Seriously. I’ve never seen benchmarks with a work factor of 5, but the OpenBSD bcrypt I’ve been able to get 30 khash/sec… I want whatever this guy is using.

You are probably thinking about oclHashcat using mask attacks. I have a rig very similar to the one you pictured, and I always do a combination of things when setting up an exhaustive attack. I first start out doing a full alpha-numeric-special exhaustion of 7 characters, a raw wordlist check from hashes.org, then a combination attack from the best64 rule set and my own personal collection, then a alpha-numeric to 10 characters. I find that this gets about 80ish percent of any of my dumps (Generally these are NTLM, MD5, SHA1, and MySQL).

So in my experience unless it’s bcrypt, scrypt, or something with rounds, then it really doesn’t matter. Raw SHA-2* and MD5 come out about the same speeds, while NTLM (the most common I deal with) is insanely optimized in oclHashcat and is one of the fastest to crack. For instance here is a 8x R9 benchmark that gives you real world stats.

Source for this claim? What makes you say this is the “bare minimum”? Also, why restrict passwords to not include special characters?

I do 20 characters alphanumeric, which gives about 120 bits¹ and is short enough to be bearable to type in by hand (or memorize) if necessary.

I do alphanumeric because I’ve had sites silently corrupt passwords that contain special characters (whereas alphanumeric is basically guaranteed to work) and they only buy you a few more bits regardless.

¹ Which is sufficient. If an attacker can iterate through 10^20 passwords per second (an arbitrary guess at the processing power of the entire world), it will take them

a trillion yearsto go through all of them. My secrets will certainly be uninteresting by then.I generally do 25. I used to do 99, but found 25 to be right around the threshold of “I can tolerably type this in when necessary”. I don’t think I’ve ever encountered the silent corruption issue, but it’s an interesting issue.

Reminds me of when I recently signed up for some website and it silently truncated my password when I logged in. I went to reset the password, and it just emailed me the password in plaintext. Yikes.

[Comment from banned user removed]

I calculate

`log((26+26+10)^20)/log(2) = 119.1`

. Regardless, no, it’s not a big difference.The thermodynamic argument for cryptographic strength (briefly, there is a certain thermodynamic minimum amount of energy required to perform any computation and merely counting to 2^256 uses all the energy in the known universe; and the second law of thermodynamics

definitelysupersedes Moore’s law) indicates that while, eventually, 20 characters may be too short, 40 characters never will be. Going beyond that is pointless and makes the password needlessly difficult to type by hand.Incidentally, performing this same physics exercise with a 20-character password tells us the bare minimum to count that high on the most efficient computer physically possible would take 31 TJ, which at current electricity prices would cost about $1M. (Practically speaking, of course, the cost to actually crack them on real hardware that actually exists would be dozens of orders of magnitude higher.) I’m comfortable saying that’s well above the value of anything protected by any of my passwords.

Thanks for the link, the thermodynamic argument is not one I’d heard before. Since this link talks about symmetric keys, how did you determine that a 40 character password is long enough for the same thermodynamic guarantee?

Passwords

aresymmetric keys, approximately. (The harder part is convertingasymmetrickeys because the difficulty of cracking them, at least for RSA keys, is not proportional to the magnitude of the key but to the square root thereof.) Brute-forcing a password with`n`

bits of entropy is (wild hand-waving) more or less equivalent to brute-forcing a symmetric encryption key with`n`

bits of entropy. A 20 character mixed-case alphanumeric password has about 119 bits of entropy; a 40-character one has about 238 bits.¹ Given that, the same argument follows: the minimum amount of energy for a (more hand-waving) “computation” is 4.4e-16 ergs, so doing one for every 40-character password will use up 2.2e37 TJ of energy, or about five orders of magnitude more than is released by a supernova.²¹ “Number of bits” is just base-2 log of the size of the password space. There are

`26+26+10 = 62`

mixed-case alphanumeric characters, so`62^20 = 7.0e35`

possible 20-character passwords; log base 2 of that is approximately 119.08.² Physicists being physicists, there is an evocatively-named unit for this amount of energy: the “foe”, conveniently memorable as ten to the

fiftyoneergs.Our hypothetical hyper-efficient computer uses about 238 thousand foe going through all the 40-charcter passwords.Thank you for providing such a clear answer :)

That doesn’t sound right.

[Comment from banned user removed]

Well, I know how diceware is supposed to work, so I can figure it out, but otherwise I’d have no idea how I’m supposed to turn five dice into six words. Usually you don’t pick the words you like. That kind of defeats the purpose.

Also, I’ll add that even six times five dice is 6^30, which is nowhere close to your bare minimum of 36^32.

[Comment from banned user removed]

The point of using dice is that people are pretty bad at picking words at random. The set of words you like is not random.

[Comment from banned user removed]

“I am smart enough to do it safely” - you probably are, but I can’t help hearing echoes of the last words spoken by every person about to do something dangerous.

~~You made an error here in your math. When combining the dice rolls, it’s not~~`6^(6*5)`

(which is 6^30) but`6^(6^5)`

(which is 6^7776).~~Comparing the correct number of diceware possibilities to a regular password we see:~~~~edit: I miscalculated 6^5 so I corrected it.~~edit: public math is hard

You’re going to have to explain to me how rolling six dice five times provides equivalent entropy to rolling a single die seven and a half thousand times.

~~Did you mean rolling five dice six times? The math works out differently for rolling six dice five times.~~~~Each roll of the die generates a number in the range 1-6. When you roll a die once, you have 6 possible numbers you could get. When you roll a die twice (once for the tens position and once for the ones position) you have~~`6*6 (6^2)`

possible outcomes. Continuing in the same way, for a five digit number, you have`6*6*6*6*6 (6^5)=7776`

possible combinations.~~Using the same pattern, if I want to generate a list of six five-digit numbers, we raise the length of the list to the number of combinations power. We want 6 five-digit numbers so the base is 6. The number of possible five-digit combinations is what we found above. There are~~`6^5`

possible five-digit numbers. So we end up with`6^(6^5)=6^7776`

.I apologize, my snark was unproductive. Your math is wrong and tedu’s is correct. Rolling

`n`

dice`m`

times is equivalent to rolling one die`n * m`

times.The particular mistake you made is

this is precisely backwards: we raise the number of combinations to the length of the list. A five digit number has ten possible digits in the first position, ten in the second, etc. for a total of

`10*10*10*10*10`

or`10^5`

possibilities. In the case of our dice, five six-sided dice gives`6^5 = 7776`

combinations, six times give`7776^6 = 2.2e23 = 6^30`

total possible permutations. (Rolling six dice five times gives`(6^6)^5 = 46656^5 = 2.2e23`

combinations as well, because`(x^y)^z = x^(y*z)`

and multiplication commutes.)Oh crap. You’re totally right. That’s what I get for doing math first thing in the morning.

No matter how you group it, there are 30 rolls of a six sided die. It’s a 30 character string with digits 1-6.

Isn’t the bare minimum given here for a generated pw while the diceware pw is for the master pw to access the pw database? Being on your own machine adds additional security.

Is this MD5? SHA2? Bcrypt? This is going to be the biggest factor here.

Some napkin math:

md5 hashes of all 8-character strings would take: 62^8 / 200,000,000,000 / 60 = 18 minutes.

[EDIT: I am bad at reading units, thanks for pointing that out] The same machine can do bcrypt with a work-factor of 5 at 100 Khash/sec, but a more likely work-factor is 12. The work factor is an exponent, so we can divide by 2^(12-5) to get 780 hashes/sec.

bcrypt hashes of all 8-character strings would take: 62^8 / 780 / 60 / 60 / 24 / 365 = 8800 years

Where did you get 100 ghash/sec for bcrypt?

Seriously. I’ve never seen benchmarks with a work factor of 5, but the OpenBSD bcrypt I’ve been able to get 30 khash/sec… I want whatever this guy is using.

The linked comments indicate that they use work factor 5 so they can compare benchmarks from years ago with current ones.

I have drastically misread the units here, will edit.

[Comment from banned user removed]

You are probably thinking about oclHashcat using mask attacks. I have a rig very similar to the one you pictured, and I always do a combination of things when setting up an exhaustive attack. I first start out doing a full alpha-numeric-special exhaustion of 7 characters, a raw wordlist check from hashes.org, then a combination attack from the best64 rule set and my own personal collection, then a alpha-numeric to 10 characters. I find that this gets about 80ish percent of any of my dumps (Generally these are NTLM, MD5, SHA1, and MySQL).

So in my experience unless it’s bcrypt, scrypt, or something with rounds, then it really doesn’t matter. Raw SHA-2* and MD5 come out about the same speeds, while NTLM (the most common I deal with) is insanely optimized in oclHashcat and is one of the fastest to crack. For instance here is a 8x R9 benchmark that gives you real world stats.

For anybody looking for the punchline from that benchmark,

…

for more than six orders of magnitude difference in performance.

(The whole thing is very interesting, though, thank you for posting it.)