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

Nikos Mavrogiannopoulos nmav at gnutls.org
Wed Mar 1 10:28:21 CET 2006

On 3/1/06, Travis H. <solinym at gmail.com> wrote:

> 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?
Not really. Ok the CBC IV needs to be non-repeating but a random repeat
isn't catastrophic (it's no good either). We don't use any modes such
as OFB or CFB and I cannot find a usage for such numbers in gnutls

> 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.
This sounds like a good idea.

> 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.
You will not gain much from that except from complication to use it.
I think the best is to open the device (kernel allocates all required
contexts) and during read produce the outputs.

> 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?"

That would be trully a good idea. Of course you have to define
your semantics, for random numbers, and try to emulate them using each host's
available devices. Otherwise it would be unknown what to expect in
every system. The problem in a library like that would be the emulation
of these devices in systems that don't support them, and then you
have to think about thread safety, forks (that might lead to producing
the same numbers etc)... It sounds like lots of work... :)


More information about the Gnutls-devel mailing list