Man page section forgotten...
[openssl.git] / doc / crypto / rand.pod
index baddd4379c898cef40b45cd6c224c2d40d55f4f7..6d748c1bb67e3bd61ad6a9d41228ee32759bbe1a 100644 (file)
@@ -101,41 +101,47 @@ the RNG state or the next random number.
 The algorithm is as follows.
 
 There is global state made up of a 1023 byte buffer (the 'state'), a
-working hash function ('md') and a counter ('count').
+working hash value ('md'), and a counter ('count').
 
 Whenever seed data is added, it is inserted into the 'state' as
 follows.
 
-The input is chopped up into units of 16 bytes (or less for the last
-block).  Each of these blocks is run through the hash function.  The
-data passed to the hash function is the current 'md', the same number
-of bytes from the 'state' (the location determined by in incremented
-looping index) as the current 'block' and the new key data 'block'.
-The result of this is kept in 'md' and also xored into the 'state' at
-the same locations that were used as input into the hash function.  I
+The input is chopped up into units of 20 bytes (or less for
+the last block).  Each of these blocks is run through the hash
+function as follows:  The data passed to the hash function
+is the current 'md', the same number of bytes from the 'state'
+(the location determined by in incremented looping index) as
+the current 'block', the new key data 'block', and 'count'
+(which is incremented after each use).
+The result of this is kept in 'md' and also xored into the
+'state' at the same locations that were used as input into the
+hash function. I
 believe this system addresses points 1 (hash function; currently
 SHA-1), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash
 function and xor).
 
 When bytes are extracted from the RNG, the following process is used.
-For each group of 8 bytes (or less), we do the following,
-
-Input into the hash function, the top 8 bytes from 'md', the byte that
-are to be overwritten by the random bytes and bytes from the 'state'
-(incrementing looping index).  From this hash function output (which
-is kept in 'md'), the top (upto) 8 bytes are returned to the caller
-and the bottom (upto) 8 bytes are xored into the 'state'.
-
-Finally, after we have finished 'generation' random bytes for the
-called, 'count' (which is incremented) and 'md' are fed into the hash
-function and the results are kept in 'md'.  I believe the above
-addressed points 1 (use of SHA-1), 6 (by hashing into the 'state' the
-'old' data from the caller that is about to be overwritten) and 7 (by
-not using the 8 bytes given to the caller to update the 'state', but
-they are used to update 'md').
+For each group of 10 bytes (or less), we do the following:
+
+Input into the hash function the top 10 bytes from the local 'md'
+(which is initialized from the global 'md' before any bytes are
+generated), the bytes that are to be overwritten by the random bytes,
+and bytes from the 'state' (incrementing looping index). From this
+digest output (which is kept in 'md'), the top (up to) 10 bytes are
+returned to the caller and the bottom (up to) 10 bytes are xored into
+the 'state'.
+
+Finally, after we have finished 'num' random bytes for the caller,
+'count' (which is incremented) and the local and global 'md' are fed
+into the hash function and the results are kept in the global 'md'.
+
+I believe the above addressed points 1 (use of SHA-1), 6 (by hashing
+into the 'state' the 'old' data from the caller that is about to be
+overwritten) and 7 (by not using the 10 bytes given to the caller to
+update the 'state', but they are used to update 'md').
 
 So of the points raised, only 2 is not addressed (but see
-L<RAND_add()>).
+L<RAND_add(3)>).
 
 =head1 SEE ALSO