+<big><b>Introduction to Random Number Generator</b></big>
+
+<br /> <br /> <br />
+<b>Overview</b>
+
+<br /> <br />
+SILC Random Number Generator is cryptographically strong pseudo random
+number generator. It is used to generate all the random numbers needed
+in the SILC sessions. All key material and other sources needing random
+numbers use this generator.
+
+<br /> <br />
+The RNG has a random pool of 1024 bytes of size that provides the actual
+random numbers for the application. The pool is initialized when the
+RNG is allocated and initialized with silc_rng_alloc and silc_rng_init
+functions, respectively.
+
+
+<br /> <br /> <br />
+<b>Random Pool Initialization</b>
+
+<br /> <br />
+The RNG's random pool is the source of all random output data. The pool is
+initialized with silc_rng_init and application can reseed it at any time
+by calling the silc_rng_add_noise function.
+
+<br /> <br />
+The initializing phase attempts to set the random pool in a state that it
+is impossible to learn the input data to the RNG or any random output
+data. This is achieved by acquiring noise from various system sources. The
+first source is called to provide "soft noise". This noise is various
+data from system's processes. The second source is called to provide
+"medium noise". This noise is various output data from executed commands.
+Usually the commands are Unix `ps' and `ls' commands with various options.
+The last source is called to provide "hard noise" and is noise from
+system's /dev/random, if it exists.
+
+
+<br /> <br /> <br />
+<b>Stirring the Random Pool</b>
+
+<br /> <br />
+Every time data is acquired from any source, the pool is stirred. The
+stirring process performs an CFB (cipher feedback) encryption with SHA1
+algorithm to the entire random pool. First it acquires an IV (Initial
+Vector) from the constant (random) location of the pool and performs
+the first CFB pass. Then it acquires a new encryption key from variable
+location of the pool and performs the second CFB pass. The encryption
+key thus is always acquired from unguessable data.
+
+<br /> <br />
+The encryption process to the entire random pool assures that it is
+impossible to learn the input data to the random pool without breaking the
+encryption process. This would effectively mean breaking the SHA1 hash
+function. The encryption process also assures that each random output from
+the random pool is secured with cryptographically strong function, the
+SHA1 in this case.
+
+<br /> <br />
+The random pool can be restirred by the application at any point by
+calling the silc_rng_add_noise function. This function adds new noise to
+the pool and then stirs the entire pool.
+
+
+<br /> <br /> <br />
+<b>Stirring Threshholds</b>
+
+<br /> <br />
+The random pool has two threshholds that controls when the random pool
+needs more new noise and requires restirring. As previously mentioned, the
+application may do this by calling the silc_rng_add_noise. However, the
+RNG performs this also automatically.
+
+<br /> <br />
+The first threshhold gets soft noise from system and stirs the random pool.
+The threshhold is reached after 64 bits of random data has been fetched
+from the RNG. After the 64 bits, the soft noise acquiring and restirring
+process is performed every 8 bits of random output data until the second
+threshhold is reached.
+
+<br /> <br />
+The second threshhold gets hard noise from system and stirs the random
+pool. The threshhold is reached after 160 bits of random output. After the
+noise is acquired (from /dev/urandom) the random pool is stirred and the
+threshholds are set to zero. The process is repeated again after 64 bits of
+output for first threshhold and after 160 bits of output for the second
+threshhold.
+
+
+<br /> <br /> <br />
+<b>Internal State of the Random Pool</b>
+
+<br /> <br />
+The random pool has also internal state that provides several variable
+distinct points to the random pool where the data is fetched. The state
+changes every 8 bits of output data and it is guaranteed that the fetched
+8 bits of data is from distinct location compared to the previous 8 bits.
+It is also guaranteed that the internal state never wraps before
+restirring the entire random pool. The internal state means that the data
+is not fetched linearly from the pool, eg. starting from zero and wrapping
+at the end of the pool. The internal state is not dependent of any random
+data in the pool. The internal states are initialized (by default the pool
+is splitted to four different sections (states)) at the RNG
+initialization phase. The state's current position is added linearly and
+wraps at the the start of the next state. The states provides the distinct
+locations.
+
+
+<br /> <br /> <br />
+<b>Security Considerations</b>
+
+<br /> <br />
+The security of this random number generator, like of any other RNG's,
+depends of the initial state of the RNG. The initial state of the random
+number generators must be unknown to an adversary. This means that after
+the RNG is initialized it is required that the input data to the RNG and
+the output data to the application has no correlation of any kind that
+could be used to compromise the acquired random numbers or any future
+random numbers.
+
+<br /> <br />
+It is, however, clear that the correlation exists but it needs to be
+hard to solve for an adversary. To accomplish this the input data to the
+random number generator needs to be secret. Usually this is impossible to
+achieve. That is why SILC's RNG acquires the noise from three different
+sources and provides for the application an interface to add more noise at
+any time. The first source ("soft noise") is known to the adversary but
+requires exact timing to get all of the input data. However, getting only
+partial data is easy. The second source ("medium noise") depends on the
+place of execution of the application. Getting at least partial data is
+easy but securing for example the user's home directory from outside access
+makes it harder. The last source ("hard noise") is considered to be the
+most secure source of data. An adversary is not considered to have any
+access on this data. This of course greatly depends on the operating system.
+
+<br /> <br />
+These three sources are considered to be adequate since the random pool is
+relatively large and the output of each bit of the random pool is secured
+by cryptographically secure function, the SHA1 in CFB mode encryption.
+Furthermore the application may provide other random data, such as random
+key strokes or mouse movement to the RNG. However, it is recommended that
+the application would not be the single point of source for the RNG, in
+either intializing or reseeding phases later in the session. Good solution
+is probably to use both, the application's seeds and the RNG's own
+sources, equally.
+
+<br /> <br />
+The RNG must also assure that any old or future random numbers are not
+compromised if an adversary would learn the initial input data (or any
+input data for that matter). The SILC's RNG provides good protection for
+this even if the some of the input bits would be compromised for old or
+future random numbers. The RNG reinitalizes (reseeds) itself using the
+threshholds after every 64 and 160 bits of output. This is considered to be
+adequate even if some of the bits would get compromised. Also, the
+applications that use the RNG usually fetches at least 256 bits from the
+RNG. This means that everytime RNG is accessed both of the threshholds are
+reached. This should mean that the RNG is never too long in an compromised
+state and recovers as fast as possible.
+
+
+<br /> <br /> <br />
+<b>Caveat Windows Programmer</b>
+
+<br /> <br />
+The caller must be cautios when using this RNG with native WIN32 system.
+The RNG most likely is impossible to set in unguessable state just by
+using the RNG's input data sources. On WIN32 it is stronly suggested
+that caller would add more random noise after the initialization of the
+RNG using the silc_rng_add_noise function. For example, random mouse
+movements may be used.
+
projects / silc.git / commitdiff