Actual entropy of a passphrase
randomsecurityrants.blogspot.com
randomsecurityrants.blogspot.com
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.
and it ignores the existence of dictionaries.
The 8K figure is a low, but realistic baseline (worst case).
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.
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.
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.
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.
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.
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).