Differences between version 15 and revision by previous author of RandomNumberGenerator.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
Newer page: | version 15 | Last edited on Thursday, April 1, 2004 11:18:59 am | by AristotlePagaltzis | Revert |
Older page: | version 14 | Last edited on Thursday, April 1, 2004 2:02:52 am | by AndersGreen | Revert |
@@ -25,12 +25,12 @@
!!! Hybrids
In [Unix] systems, there are commonly random(4) and urandom(4) devices. They are regular pseudorandom number generators, but include a twist that lets them generate higher quality random numbers than otherwise expected: their seed is periodically perturbed using using low-level timing information from entropy sources which only the [Kernel] has proper access to, such as the network, mouse, and keyboard. These generators are considered a sufficient for everything except highly sensitive cryptographic applications such as PublicKey generation (see RFC:1750 on best practices).
-;: "
The generation of random numbers is too important to be left to chance."
%%% -- Robert R. Coveyou
+;: ''
The generation of random numbers is too important to be left to chance.''
%%% -- Robert R. Coveyou
In [Java] systems, instances of the class __java.security.!SecureRandom__ operate in a similar fashion. Making instances of this class can take several seconds while the [JVM] tries to russle up entropy.
The weakness of such a hybrid approach is that while its inputs are hard to predict from outside or spy on from inside the system encapsulated by the [Kernel] or the [Java] VirtualMachine, it may itself may be separated from the hardware by a middle man. A [JVM] commonly runs as a regular process under control of an OperatingSystem. So does the [Kernel] of a VirtualPrivateServer. In such a situation it is possible predict the generated sequence or even to force the generator to produce repetitive results.
----
CategoryCryptography