Differences between current version and predecessor to the previous major change of RandomNumberGenerator.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Thursday, April 1, 2004 11:18:59 am | by AristotlePagaltzis | |
| Older page: | version 12 | Last edited on Friday, March 26, 2004 3:27:25 am | by AristotlePagaltzis | Revert |
@@ -7,9 +7,9 @@
!!! Pseudorandom number generators
A pseudo random number generator such as offered by the random(3) and rand(3) functions of the standard [C] library generates numbers using mathematical [Algorithm]s.
-;: ''Anyone attempting to produce random numbers by purely arithmetic means is, of course, in a state of sin.'' --JohnVonNeumann
+;: ''Anyone attempting to produce random numbers by purely arithmetic means is, of course, in a state of sin.'' %%%
--JohnVonNeumann
An inevitable consequence is that such a generator has a "period", which means that it produces a repeating sequence of numbers. The proof of this derives from the fact that computers are [FiniteStateMachine]s. With a good algorithm though, the period length can well reach billions of numbers.
However, designing such an algorithm is difficult terrain which requires thorough understanding of statistics and very sharp math skills. __Do not attempt to roll your own.__ Most naive attempts at handrolled pseudorandom number generators have alarmingly short period lengths. Often, hapless programmers will try to make a "better" generator by lumping together two different algorithms with decent period lengths each -- but the result is almost invariably a generator with a ''shorter'' period!
@@ -24,11 +24,13 @@
!!! 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
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 [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
the hybrid
generator 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 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
