[gnutls-dev] Re: alternative /dev/random

[Travis H.]

On 2/28/06, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> 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.

Speaking of IVs,
Is there a need in gnutls to have a sequence of N-bit values that
needs to be first and foremost nonrepeating and secondly
unpredictable?  For example, some block modes need different IVs every
time, but don't necessarily need to be unpredictable.  In such cases,
I am considering using a N-bit cipher in CTR mode to create such
nonrepeating sequences.  IIRC the Lion cipher can be scaled to various
bit widths, and so I could create non-repeating sequences. 
Furthermore, one could return the state to the userland process
requesting it and read it back each time they need a number, so the
kernel would not have to allocate resources for maintaining internal
state.

I am considering writing a cross-platform userland library, first in
python then in C, for access to /dev/random devices, so that the
application need not concern itself with "am I running on FreeBSD,
where /dev/random is yarrow, or am I running on Linux, where
/dev/random is a true RNG?"

Thank you for the link to fortuna, I will investigate that further!
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484