Anonymous user
Random Number Generator: Difference between revisions
Add adversarial entropy from Nullplan's version
| [unchecked revision] | [unchecked revision] |
(Incorporate timing into "sampling manually") |
(Add adversarial entropy from Nullplan's version) |
||
Line 69:
The challenge is finding sources that are (paradoxically) reliably random and difficult to influence and observe from outside. For each of these sources, an estimate must be made of how much entropy they contribute. Measurements add their respective amount of entropy to the pool, while reads decrease the entropy.
Because you have full control of this generation method, you can also incorporate the values generated by hardware generators
When using timing as entropy source, the timestamp read should be as precise as possible. The TSC works well for this. Gauging the entropy gained from that operation requires knowledge of the timing window for the event to occur in and the tick rate of the TSC. For example, if a TSC has a tick rate of 3 GHz and an event has a 10ms window to occur, then the TSC read can have any one of 30 million values, which means the entropy gained from this is ca. 24.8 bits. Were the TSC slower, only 1 GHz, then the entropy would only be ca. 23.2 bits.
==== Adversarial entropy ====
If an adversary can somehow observe the state of the entropy pool and contribute their own entropy into the pool, then it is possible that they would provide entropy in such a way as to force the entropy pool into a lower entropy state. A simple example would be an entropy source periodically checking if a certain bit in the pool is set, and then providing entropy until it is clear. This way, for most of the time, that given bit is clear, and the number of possible states the entropy buffer can be in is halved. A more sophisticated attack is described on DJB's blog: https://blog.cr.yp.to/20140205-entropy.html
== Cryptographically secure pseudorandom number generators ==
| |||