          Copyright (c) mjh-EDV Beratung, 1996-1999
     mjh-EDV Beratung - 63263 Neu-Isenburg - Rosenstrasse 12
          Tel +49 6102 328279 - Fax +49 6102 328278
                Email info@mjh.teddy-net.com

    Author: Jordan Hrycaj <jordan@mjh.teddy-net.com>

   $Id: README.RANDOM-GENERATOR,v 1.1 1999/10/18 22:31:39 jordan Exp $

   This library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Library General Public
   License as published by the Free Software Foundation; either
   version 2 of the License, or (at your option) any later version.

   This library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Library General Public License for more details.

   -----------------------------------------------------------------

About randomness:

Well, I thought about several approaches to generate random numbers that
satisfy some cryptographic requirements.  Some nice random generator is 
found in the gnupg package that implements OpenPGP.  However, that stuff
turned out to be not terribly portable, and is was a bit slow.  Anyway, I
could exploit several ideas.  


This module:

Contrary to the gnugp approach, the cipher layer module is expected to
run for a long time.  In each protocol block, some generated random bits
are to be passed to the receiver, and v.v. are expected to be received.

Only when initializing private keys, the cryptographically secure random
data must be used.  Most of the other stuff is public, anway.  So, crypto
random data are needed only, when:

	1. a private El Gamal key is generated (100 bytes, and more)

	2. a private session key is generated (16 bytes)

	3. probably some random seed in each data block (4 bytes)

Basically I need to see what kind of "randomness" I would have in this
cipher layer module:

	4. detailed current time when certain points in the source 
           code of algortithms are passed

	5. randomness (besides padding) in the data received (see 3.)
	
	6. the current pid, parent pid from forking

	7. certain variable addresses

Some problem occurs with topics 3. and 5.  When one partner is only
sending, it passes random bits to the receiver without gaining much back.
So, the sender will loose entropy.  to meet this, one could exploit the
sending algorithm (using points 3. and 7.) with a higher weight than the
receiver.


Practical considerations about the random pool:

As many others did, I programmed a simple fifo of fixed size, called random
pool.  This fifo is stuffed with all kinds of data up until it is full, in
which case the data in the pool are condensed to a third of the original
size, say. Condensing is done using a hash function.  

And this stuffing and condensing procedure goes on until the "density" is
thought of some cryptographically feasible level.  From now on, random data
may be tapped while new data fill up the pool.  Of course, incoming data
cannot be tapped up until they are condensed at least once (in this module
they are always condensed to the "cryptographically feasible" level.)

Tapping data must be at a slower rate than fillin in data so that the 
density does not sink below a minimum level. The density is calculated as

   rho = (number_of_data_in - number_of_data_out) / current_pool_size.

So, when you need data and the level becomes low, the pool must be
stuffed with whatever you get (which might not be very random, though.)
The stuffing data routine should give a warning about what it's doing. I
do not see a chance to do anything else in real life than printing a
message while running unattendend over a longer time.


Some references: 

"Cryptanalytic Attacks on Pseudorandom Number Generators", J. Kelsey, 
	B. Schneier, D. Wagner, and C. Hall, Fast Software Encryption, 
	Fifth International Workshop Proceedings (March 1998), 
	Springer-Verlag, 1998, pp. 168-188.
	http://www.counterpane.com/pseudorandom_number.html

"Applied Cryptography, Second Edition", Bruce Schneier, John Wiley & Sons, 
	1996, pp 421-428 (17.4 Real Random-Sequence Generators)
	http://www.counterpane.com/applied.html
