Penguin
Diff: RandomNumberGenerator
EditPageHistoryDiffInfoLikePages

Differences between current version 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
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