SILC Core Library
    SILC Auth API
    SILC Channel API
    SILC Command API
    SILC ID API
    SILC ID Cache API
    SILC Modes
    SILC Notify API
    SILC Packet API
    SILC Argument API
    SILC Private API
SILC Math Library
    SILC Math API
    SILC MP API
SILC SFTP Library
    SILC SFTP API
    SILC SFTP Filesystems
SILC Utility Library
    SILC Buffer API
    SILC Buffer Format API
    SILC Buffer Utility API
    SILC Hash Table API
    SILC Log and Debug API
    SILC Memory API
    SILC Mutex API
    SILC Thread API
    SILC Net API
    SILC Schedule API
    SILC Socket Connection API
    SILC Protocol API
    SILC Util API
    SILC Zip API
    SILC List API
    SILC Dynamic List API
SILC Key Exchange Library
    SILC SKE API
    SILC SKE Status
SILC Client Library
    SILC Client API
SILC Crypto Library
    SILC Cipher API
    SILC Hash API
    SILC HMAC API
    SILC PKCS API
    SILC RNG API
SilcRNGAPI

DESCRIPTION

 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.

 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. 


 Random Pool Initialization

 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.

 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.


 Stirring the Random Pool

 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.

 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.

 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.


 Stirring Threshholds

 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.

 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.

 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.


 Internal State of the Random Pool

 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.


 Security Considerations

 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. 

 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.

 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.

 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.

 Currently the SILC's RNG does not use random seed files to store some
 random data for future initializing. This is important and must be
 implemented in the future.

 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.

>> SilcRNGAPI