It seems like it's (ab)using the metastability[1] of the dual inverter circuit as the input source. Since metastable states can persist for arbitrary long periods (with asymptotic probability), the bias testing and reset mechanisms are needed.<p>I assume they're controlling the system to ensure that the thermal noise dominates, and that the de-bias feedback loop and signal conditioner can strip out any low frequency thermal changes (like, temperature forcing through heavily loading CPU).<p>There are some really neat attacks that use thermal system properties to leak or force information. A submission from a while back: <a href="http://news.ycombinator.com/item?id=2872274" rel="nofollow">http://news.ycombinator.com/item?id=2872274</a> struck me as particularly sneaky.<p>[1] <a href="https://secure.wikimedia.org/wikipedia/en/wiki/Metastability_in_electronics" rel="nofollow">https://secure.wikimedia.org/wikipedia/en/wiki/Metastability...</a>
It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available source of randomness : the timestamps of other customer's orders.<p>Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
I thought the 40-bit keys were used due to cryptographic export restrictions, and not lack of randomness?<p><a href="http://en.wikipedia.org/wiki/40-bit_encryption" rel="nofollow">http://en.wikipedia.org/wiki/40-bit_encryption</a><p>Seems to agree with me.
Now that's a perfect example of something that seems obvious in hindsight, but obviously wasn't since the problem has existed for so long without a solution.<p>It's also nice to see a more EE oriented post on hacker news now and again.
"The nominally random number Netscape [1.x] used to form a secret key was based on just three values—time of day, process identification number, and parent-process identification number—all of them predictable. This allowed the attackers to reduce the number of keys that they needed to try, and to find the right one much sooner than Netscape had anticipated."<p>Another reason to disable SSLv2 on servers, BTW.