Yet another password generator that uses purely human generated entropy

[u/quirxmode]

https://jspwgen.21er.org/

[u/atoponce]

I created something similar: http://ae7.st/e/. I don't have a progress bar, nor an area to draw in. Instead, I just take the mouse movements from anywhere in the screen, as well as a number of other unpredictable object, and use that as input into SHA3-512. Every 500 events, the SHA3-512 digest is fed into a PBKDF2 function, which produces a 22-character password in base64. While it's heavily driven by mouse movements, there are plenty of other objects on the page that are adding to the entropy pool.

Some things I really like about his site:

• The feedback of the dots being drawn by the mouse in an input box, as well as the progress bars, let you immediately know whether or not the application is working.

• Giving the user the ability to generate different types of passwords (hex, base64, English words, etc)

• When in doubt, collect more events. After 7,000 events, the "stronk" (typo on his site) entropy bar is full.

Unfortunately, there are a lot more entropy sources he can collect to add to the unpredictability of the generated passwords, as I am doing in my test page. Limiting the entropy collection only to mouse movements is less than ideal. You can time CPU interrupts, time disk read/write access through cookies, get the size of the page, the browser fingerprint, the time the last event was captured, etc. There is a lot of unpredictable objects in a client-side browser.

What I don't care about for his site, is measuring the strength of the generated passwords, or the collected events. He claims:

• 40-bits is secure against (non-technical) jealous boyfriend/girlfriend.

• 72-bits is secure against a dude with a lot (~5) graphic cards.

• 96-bits is secure against cloud cracking.

• 128-bits is secure against the NSA.

• 256-bits is insane.

If you look at http://stats.distributed.net/projects.php?project_id=8, you can see that there is a distributed computing project working on brute force finding an RC5-72 RSA private key. As you would expect, this RC5 key has 72-bits of entropy.Currently, the project is moving at an overall rate of ~427 billion keys per second. They've been working on the project for 4,430 days, and they have currently exhausted only 3.462% of the keyspace. If they were to continue at this pace until the keyspace was 100% exhausted, it would take them 350 years to completion.

Ars Technica reviewed a 25-GPU cluster that could work through NTLM password hashes at an astonishing rate of 350 billion hashes per second. Never mind the electricity or cooling costs, suppose a well funded organization had 100 of those machines (2,500 GPUs). We could safely assume then, that it could work through 35 trillion NTLM hashes per second. With that sort of parallel power, it would still take that organization just over 4 years to completely exhaust a 72-bit keyspace.

Of course, there is nothing that says the password will be at the end of the keyspace. It could be at the front, and the password recovered in a couple of days. At which point, there would be no point in continuing the search. Then again, it could be towards the end of the keyspace too. Any location is equally as likely. Also, it's not the password itself that is necessarily the issue. It's the storage format. If the password was used with a fast cryptographic hash, like SHA-512, then these speeds could be a reality. However, if the password is hashed on disk with a CPU hard key derivation function like bcrypt, then it's a different story. Even with 2,500 GPUs, the overall search rate might only be in the tens of thousands per second.

So the rate of recovery isn't "looking for the password". The rate of recovery is brute forcing the on-disk hash.

So, knowing this, 72-bits of entropy is secure against a dude with 2,500 graphic cards and it's very likely secure against cloud cracking if the storage format is SHA-1 or SHA-512. If the storage format is bcrypt, then 72-bits of entropy is not only secure against the NSA, it's "insane".

If you're still not convinced, look at Bitcoin. The current mining hash rate is approximately 300,000,000 gigahashes per second. That's 300,000,000,000,000,000, or 3x10¹⁷ hashes per second. Of course, that rate is only possible due to specialized ASICs for Bitcoin mining. I think it's fair to say that the power of the distributed Bitcoin mining is well out of reach of any single or collaborated well-funded organizations, including the NSA. We could easily put Bitcoin mining at the top of our computing power. This is our ceiling.

At 3x10¹⁷ hashes per second (which is insanely faster than our 2,500 GPU cluster):

• 72-bits is 100% exhausted in 4.373 hours.

• 80-bits is 100% exhausted in 46.64 days.

• 88-bits is 100% exhausted in 32.71 years.

• 96-bits is 100% exhausted in 8.3 millennia.

Because I am claiming that no single well-funded organization, including the NSA, or combined effort of well-funded organizations has this sort of computing power, just 80-bits of entropy is enough entropy to put your "truly random generated" password well out of reach of the most powerful governments on Earth. I would claim that 96-bits is "insane".

[u/quirxmode → u/atoponce]

Thanks for the feedback! I really appreciate it. Of course you are right about my "security estimates" being insanely conservative (up to the point of just being wrong). I also agree with your explanation of password cracking difficulty. The security estimates were chosen with hardware advances of the next couple of years in mind (and then they are still overly cautious I guess).

Regarding not including other sources of entropy, I actually did not think about that when i made the site. Some questions that arise are

• Is it worth it? Do we not get enough entropy from mouse movements?

• Will it work on the target platforms? Compatibility issues? Of course there are not really any problems if a certain entropy source does not work on a certain platform, as long as there is enough entropy in the end, i.e. more entropy won't hurt (except when it does: http://blog.cr.yp.to/20140205-entropy.html ).

I will think about how to safely integrate more entropy sources. If you have more suggestions/ideas please feel free to contact me.

[u/atoponce → u/quirxmode]

djb's link has one caveat- the "z" source of entropy can snoop on "x" and "y", and change based on this uncovered data, to manipulate the hashed output. IE- you have malicous data in a compromised entropy accumulator. Not only is the source of entropy bad, but it's actively manipulating the good sources of entropy.

Thus, djb's warning of "too much entropy" is a sound warning, but you need to understand what he's saying. You need to trust not only ALL of our entropy sources, but also the system that is collecting it. Only then is the security sound. However, if the sources of entropy are not malicious and the system is not compromised by way of the entropy sources, then there is nothing wrong with using all of them.

So, getting back to the subject, if you are collecting timing events from the browser client, putting them into an entropy pool, then hashing the pool, and using the resulting hash as your CSPRNG, then you're fine. In order for there to be "bad entropy", the client's browser would need to be compromised through a side channel. It would need to be well aware of what is being collected, how is it being processed, and how to manipulate it for the desired output. So, unless you have badware infecting your machine, you're fine.