The evolving high-confidence ultra-high
entropy pseudo random number generator
Click the mouse or press a key to obtain the final 256-bit high-entropy data to be used to key the
local pseudo-random number generator (PRNG).
See the following for details and complete explanation . . .
It is well known that a stream of high-quality pseudo random numbers can be generated by using a cryptographic cipher to encrypt an incrementing counter. (Note that this essentially the scheme used by GRC's Perfect Paper Passwords system):
As shown above, to generate one of 'N' unpredictable pseudo random integers falling in the range from zero (0) to 'N-1', used to choose one character from a larger set of characters, we increment a 128-bit counter, encrypt the counter's new value under the influence of a fixed 256-bit key, then take the remainder (modulus) of dividing the 128-bit result by 'N'. This process can be repeated as often as necessary as long as the 128-bit input counter is never allowed to wrap-around, since it would then begin repeating its original count values.
As you can see, there's nothing truly “random” about this approach. In fact, quite the opposite is true: The same input counter value encrypted under the same cipher key will always produce the same result. But the value and power of this simple scheme is that the output characters are impossible to practically predict as long as the cipher's key is unknown to anyone trying to guess the system's output.
A 128-bit counter generates 340,282,366,920,938,463,463,374,607,431,768,211,456 values before it begins to repeat. So this application's need for only a small handful of pseudo random numbers means that we don't need to worry about “reseeding” our pseudo random number generator with a new key before the counter's value wraps around because, for all practical purposes, it never will.
But! . . . What we DO need to consider is where and how we get the one 256-bit cipher key that we need to determine the pseudo random sequence? It must be obtained in such a way that the user of our Passcode Designer can trust that it is absolutely unknowable and unpredictable by any outside agency, including GRC. And THAT is the purpose of this page!
A trustworthy client-side (browser-based) passcode creation system needs to be based upon a high-entropy (highly random) “seed” so that it can produce passcodes that absolutely cannot be predicted by attackers. It is easy for us to obtain such a seed from GRC, since GRC's server maintains a high-entropy system used to drive its very popular Perfect Passwords page. But that would mean that GRC would know the seed being used to generate your passcodes, which is no way to design a cryptographically secure system.
While GRC is absolutely trustworthy, and has no interest in knowing anyone's passcodes, we want to be unable to respond to a court order requiring us to reveal whatever we might know. Since we already retain no logs of any kind of any server activity, it's already impossible for us to respond, but since it's easy for us to go further, that's what we have done here:
We start with a unique ultra-high-entropy seed received from
GRC, then we add further entropy to it locally so that
GRC will have no idea what final seed was used.
It's important to start with a unique high-entropy seed (which is easily provided by GRC) since we may not be able to guarantee the addition of a huge amount of local entropy. But we don't need to add much, only enough to make the final result unknowable by GRC's server. And entropy (randomness) is additive. Adding additional entropy to something that already has a guaranteed high level, only increases its randomness and makes the result even more secure.Referring to the numbering show above, this is the source and meaning of each of the sections of data shown above:
|This is the original, 256-bit, guaranteed-unique “starter seed” delivered by GRC with this instance of this page. This seed has never been delivered before, and will never be delivered again. It is guaranteed to be unique. The seed is transmitted as a short-lived session cookie named "prng" (pseudo random number generator) in the response headers of this page. Since this page will only allow itself to be served by GRC's server over an encrypted and authenticated secure https: (SSL/TLS) connection, observation of the cookie's seed value is protected from eavesdroppers. And since this seed is further randomized after its receipt (see the following sections), even knowledge of it would provide little value to an attacker. As stated above, its purpose is to provide a high guaranteed lower level of entropy, which the user's browser then further increases.|
|In the interest of using all of the entropy available (because, why not?), the page also monitors and collects every movement of the user's mouse. Some mouse movement is likely and perhaps even unavoidable. And every specific unpredictable motion pours additional “uncertainty” into our ever-growing bucket of entropy (which is already pretty much overflowing). So we continuously collect all mouse movement data (X & Y position and time) and pour it all into our ever-growing entropy pot.|
|Whenever the mouse is moved (at all) or any mouse key is pressed or released, or any keyboard key is pressed, released, or allowed to repeat, we capture the count of that event, the time of that event and, in the case of the mouse movement, the mouse's new position and feed all of that into an evolving cryptographic message digest (a 256-bit SHA256 hash).|
|It's interesting to witness the comprehensive scrambling power of a cryptographically strong hashing algorithm. The latest 256-bit hash of all previously collected data is continuously presented on the page. When this technology is eventually used to key a cipher-based pseudo-random number generator, the latest hash value will be used as the cipher's new key.|
As a pure browser compatibility check, since the Passcode Designer will be utilizing mouse rollovers to help indicate that some graphical elements can be clicked upon (for those who refuse to read the manual), I want to verify that my code for rollover handling is also cross-browser. So . . . if you mouse over the text below, PLEASE let me know if it DOESN'T change! (Note: This is NOT expected to work with non-mouse-based touch interfaces which inherently lack “hovering” capability.)
And thanks VERY MUCH in advance for any feedback you can provide about the functioning, and especially the non-functioning, of this page under any whacky platform you may be able to conjure up!
As we see from the succession of additional released, although this first release worked well in the general case, it had a number of problems that were resolved, one by one, with the following releases.
|Cookies are bad|
|Collecting “history” is bad|
|Fixing rollover animation hesitancy -&- Getting more client-side entropy|
Gibson Research Corporation is owned and operated by Steve Gibson. The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson