lloyd at randombit.net
Thu Jan 8 11:26:59 EST 2009
On Thu, Jan 08, 2009 at 04:49:57PM +0100, Rickard Bondesson wrote:
> What is, according to your opinion, the best way of incorporating a
> TRNG hardware device into a Botan RNG? I have an USB dongle called
> Araneus Alea I (http://www.araneus.fi/products-alea-eng.html) which
> is accessed through the libUSB. It generates true random data.
> Write a subclass to RNG which calls the dongle via libUSB.
If you strongly trust the Alea will always produce good randomness,
this is a path. However the web site states the data rate is around
100 kilobits/s (about 12 kibibytes/s), which is substantially slower
than a software PRNG. AutoSeeded_RNG, which is formed by wrapping
HMAC_RNG (a design which itself has good security properties) with the
X9.31/AES PRNG (just in case), runs at over 3 MiB/s on a 2 GHz
> 2. Write an interface to the dongle similar to /dev/random and add
> it as an entropy source in one of the existing subclasses.
This seems the best solution to me.
Currently, an HMAC_RNG will only kick off a reseed periodically, and
only with a fairly limited buffer (192 bytes between the fast and slow
polls, which in the case of the Alea would presumably both read from
the device). Depending on your operational requirements it might be
necessary/useful to add further hooks in the entropy source classes
which allow the PRNG object to query:
- How many bytes to read per poll
- How often to poll (perhaps as a minimum/maximum interval?)
If this becomes necessary let me know and I'll start experimenting.
Technically this would not be a true RNG; to get that you would need
to have the incoming rate of randomness meet or exceed the output rate
(once again limiting output to about 100 kilobits/s, plus whatever
could be gathered from the other system pollers).
> 3. Write a subclass which talks to an interface similar to
> /dev/random. It takes the path to the device file as an argument to
> the RNG constructor. Then also write an interface to the dongle
> similar to /dev/random
This is nice in the general sense, but does of course add another
level of abstraction (and buffering) between the device and the RNG
compared to (2). Also it would probably add more work - a pure libusb
implementation, if I'm understanding things correctly, would work on
Linux, the BSDs, and OS X.
More information about the botan-devel