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 Payload 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