[gnutls-dev] Re: living without global variables

[Werner Koch]

On Mon, 09 Jan 2006 14:48:43 +0100, Simon Josefsson said:

> process, it will generate the same random data in two processes after
> a fork().  Libgcrypt now detect this and re-seed itself when this
> happen.  There may be similar issues with threads too.

Handled too.

> /dev/random and /dev/urandom would work good on most desktop PCs.  If

The quality of these devises is not very good and thus Libgcrypt adds
another layer.  When unsing Linux there is even tghe problem that they
both work on the saqme pool and thus any read to urandom depletest the
pool. 

Reading just a random seed is not sufficient because the threat model
we use is that random numbers available through libgcrypt's API should
not be predictable if a user can read other resources than those of
libgrypt's process.

> you need something faster or better, write a daemon that collect
> entropy, and make it serve data in /dev/*random.

> This approach would also reduce complexity in libgcrypt.

I'd really like to do that but there is a secre bootstrap problem:

To convey the random bytes from the daemon to the consumer process
(i.e. libgcrypt's code) one need to use an IPC mechanism.  I have not
anaylyzed how we could make use of shared memeory but I am pretty sure
that this will won't be easy to get secure.  Thus the remaining
alternative is only a Unix domain socket.  This would be pretty
straightforward to implement and on some OS this would even allow a
system daemon to be implemented as there are facilities for the daemon
to detect the uid of the connecting client (we obviously want to
separate generated random as much as possible).

Okay, that will work but we would put all our eggs (in particular the
random numbers used to create keys) into that mechanism and hope that
there are no vulnerabilitiesin the kernel allowing to eavesdrop on the
internal buffers.  That violates our security principle and introduces
a hard to audit code path.

The obvious solution for this is to encrypt the data passing through
IPC.  But how?  DH KEX should work nice here because we don't consider
active attacks to be mountable easier than penetrating the actual
libgcrypt or rng-daemon process.  But well, we bneed random here again
- how do we get it then?  Classical problem :-(

You might now say, get rid of all these paranoid principles.  Well,
this will obviously solve this and many other problems but weakens the
system too much and libgcrypt would sone become the primart target of
attack and not the application itself.

We need a better and secure OS kernel and not all these Linux and BSD
monsters.  The RNG belong into a daemon which allows controlling how
much entropy a process, may suck from the system and the kernel itself
needs to provide a secure IPC mechanism.


Salam-Shalom,

   Werner