> This is the same as true 7 byte "random" password (0-255).

Characters 0 through 31 and 127 are "un-type-able." So for each byte you only have 223 potential variations.

Plus, frankly, I cannot follow the author's maths. Let me reword it to be more straightforward...

- In a random character password it has a range of 223 characters.

- In a random English word password it has a range of 8,000 words (worst case).

- Assuming a length of 8 typeable characters (223 character set) you'd get 6115597639891380481 permutations

- Assuming a length of 5 English words (8K set) you'd get 32768000000000000000 (530% higher) permutations

That ignores the fact that in a word-password people can still capitalise words, and use other punctuation (e.g. ? ! . and so on at the end, commas in the middle, capitalise names, and so forth). An 8K vocab where everything is lowercase and no punctuation at all is absolute worst case.

I think the best way to settle this argument is not through maths anyway, it is through study. Take x test subjects and have them record a dozen passwords using both methods (English words, and random characters) and then look at the "real world" variations.

I suspect in the "real world" humans naturally build more secure pass phase passwords, not because it is mathematically stronger (although I believe it is) but because even without trying they come up with more variable sentences.

>That ignores the fact that ...

and it ignores the existence of dictionaries.

I'm not sure I follow. The author was citing the number of words different groups of people typically know, this is a good starting point as few people know (or use) every single word in the English dictionary.

The 8K figure is a low, but realistic baseline (worst case).

yes, i understand that.

what i meant was that, if you wanted to use less common words, all you would have to do is look up a word in the dictionary.

besides, whilst many people may only know 8000 or so words, the set of 8000 would vary significantly, i'd imagine.

Well, I don't get the point.

The conclusion I take from that is that yes, they do work. They are no silver bullet, mind you, but they work. Yet, I'm not convinced that's the point the author is tryin got make.

By the last table, a 6 words passphrase is all that one would ever need to protect something in a civilization that does not have an entire star to spend on breaking it. That's quite good.

EDIT: But then, that strength is a gross overestimation and any serious calculation needs some extra analysis.

Hmm - so this was posted about 3 hrs ago by the author of the blog and now the post is unavailable and the blog has no other posts.

Yah I don't buy this... something is fishy about the math.

Maybe this is more true if all the words in your vocabulary were the same length (15 character passwords required made up of a list of words 5 characters long or something).

It's important to understand that most crypto algorithms don't actually use the passphrase for the symmetric key. It's hashed into a number. For example for AES, you have a choice of 64, 128 or 256 bits. No matter how good your passphrase, the actual key will be one of those bit lengths.

Which is why cracking tools don't just search the entire n-bit space, they instead generate extremely long lists of plausible passwords, hash them, and try those.

I've forgotten the passwords to some important encrypted documents, so I tried a few of the crackers.

They only sort of work. For example one has a choice of brute force or a dictionary, but not a combination of the two.

Also they do a lot of calculation they don't need to. Rather than hash every word in a dictionary every time they are executed, they could has them all just once, then save the hashes in a file.

Some offer the option of CPU implementations, NVIDIA CUDA or OpenCL. My MacBook Pro supports all three - lots of Macs have multiple cores, as well as both NVIDIA _and_ AMD CPUs. What I'd like to see is all three ways going simultaneously, but they don't do that.

Now it's not like I couldn't "use the source, Mike". It's just that I haven't actually done so yet.

"Rather than hash every word in a dictionary every time they are executed, they could has them all just once, then save the hashes in a file."

That's (part of) why any competent password storage system uses salt. It completely defeats precomputed tables.

For your first "problem", ocl-hashcat hybrid attack deals with that nicely. It also does use the CPU quite extensively for the bits the CPU is good at, so not sure where you're getting the idea that none of the common crackers do so.

I look at their source.

The ones I actually tried appear to have only been implemented as far as required to crack the author's own archives, then were posted as-is.

I'll have a look at ocl-hashcat, I had not heard of that one.

On my macbook pro, I have a core quad xeon, which has hyperthreading, so sorta kind 8 CPUs, and two GPUs. I don't recall whether one is amd or if they're both nvidia. I do know that apple made some macs that had both vendors' gpus.