Differences between version 11 and previous revision of RandomNumberGenerator.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 11 | Last edited on Friday, March 26, 2004 3:26:38 am | by AristotlePagaltzis | Revert |
| Older page: | version 10 | Last edited on Friday, March 26, 2004 2:05:42 am | by AristotlePagaltzis | Revert |
@@ -23,12 +23,12 @@
See also: srand(3), srandom(3), drand48(3), erand48(3), jrand48(3), lrand48(3), mrand48(3), nrand48(3), srand48(3)
!!! 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 sufficiently good generator
for everything except highly sensitive cryptographic applications such as PublicKey generation (see RFC:1750 on best practices).
+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).
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], the
[Kernel
] itself may be separated from the hardware by a middle man. This is the case if it is
run as UserModeLinux, f.ex. In such a situation it would be possible to cause __/dev/random__ to produce repetitive results.
+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
[Java
] VirtualMachine, it may
itself may be separated from the hardware by a middle man. This is the case with a [Kernel]
run as UserModeLinux, f.ex, and almost always the case with a [JVM] which usually runs as a regular process under control of an OperatingSystem
. In such a situation it would be possible to cause __/dev/random__ to produce repetitive results.
----
CategoryCryptography
