[gnutls-dev] alternative /dev/random

[Nikos Mavrogiannopoulos]

Hello,

 based on the last discussions on the list about the Linux
/dev/random and urandom, we decided to look on this issue
further. For many reasons that have to do with the
gathering of random events and functionality (i.e. it is not trivial
to create a thread safe random number implementation),
we believe that the random generator should be part
of the operating system. Unfortunately the Linux' random
generator is less than optimal. Some reasons:
1. It is way too slow and does not offer a faster but lower
 quality prng (for less important stuff such as IV's,
 padding etc)
2. /dev/random is blocking that may cause denial of service
 if you use it.
3. Using /dev/urandom will depleat the entropy of
 /dev/random as well, thus although we don't block
 other applications will.
4. Cannot use random events that may be known to attackers
 such as the network events.

What would we like from a kernel implemented random generator?
At least for gnutls two devices would be sufficient.
/dev/urandom: to generate session and private keys
/dev/arandom: to generate anything else (such as IV's)

The primary concern of the first should be to be unpredictable,
whilst the second should focus on being fast. A question might be
why do we need /dev/arandom? There are non cryptographic
uses of random numbers (IV's, some padding data) that have
different requirements and thus should not depleat the kernel's
entropy the same way as a key generation. There are also
non-cryptographic applications, that could use that instead.


We initially implemented an AES-CTR based prng based
on the idea of /dev/arandom of OpenBSD to overcome some
of these limitations. But then we came across the fortuna
implementation for the Linux kernel:
http://jlcooke.ca/random/

Although we haven't checked the implementation, the fortuna
algorithm seems an ideal algorithm to be used as a kernel
prng. It is about 10 times faster of the current prng and does
not have the limitations discussed above.

Thus if your system had one of the previously discussed problems,
we'd like to suggest you to try this kernel prng implementation
and discuss it in this list.

regards,
Nikos and Simon