Hardware RNG speed

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Hardware RNG speed

Michael Alexander Hamburg
Hello to the list,

I'm working on a cryptography project, and one of the things the project
requires is a moderately high-bandwidth source of truly random numbers.
To accomplish this, I set up OpenBSD on a board with a (Soekris) Hifn 7955
accelerator card, but the rate I'm getting by reading out of /dev/srandom
is pretty low (200B/s).  However, this has to be coming from the card,
because the machine has no other reasonable source of entropy other than
the network: no hard drive, no keyboard, etc.

Now, unless the card's specs are deceptive, its random number generator
must support a higher rate than this: it claims 70 1024-bit Diffie-Hellman
key exchanges per second, and each such key exchange requires a full
1024-bit random number, which comes out to 8.8kB/s.  The minimum data rate
for my application is about 1k/s, and I would strongly prefer not to use a
PRNG.

Is there a more direct way to query the RNG?  random(4) claims that the
RNG is not mapped directly to a device (/dev/random is not currently
implemented), but rather that it periodically refreshes the system entropy
pool.  Is there a way to force this to occur more often, or to transfer
more data?  Or do the numbers lie, and I'm getting all the data I can?

Thanks for your time,
Mike Hamburg

P.S. I'm looking at different sources of random numbers, and cost and
integration are important factors.  Would an AMD Geode LX or VIA C3 or C7
processor's on-board RNG provide a significantly higher data rate than
a Soekris card, at a comparable quality?

Reply | Threaded
Open this post in threaded view
|

Re: Hardware RNG speed

Theo de Raadt
> I'm working on a cryptography project, and one of the things the project
> requires is a moderately high-bandwidth source of truly random numbers.

...

> P.S. I'm looking at different sources of random numbers, and cost and
> integration are important factors.  Would an AMD Geode LX or VIA C3 or C7
> processor's on-board RNG provide a significantly higher data rate than
> a Soekris card, at a comparable quality?

Until you can justify actual real scientific reasons why you cannot
use it, I think you should use arc4random().

And I am entirely serious.  The entire idea in OpenBSD is to have many
consumers, as this strengthens the source.

Reply | Threaded
Open this post in threaded view
|

Re: Hardware RNG speed

Jason Crawford
In reply to this post by Michael Alexander Hamburg
On 12/19/05, Michael Alexander Hamburg <[hidden email]> wrote:

> Hello to the list,
>
> I'm working on a cryptography project, and one of the things the project
> requires is a moderately high-bandwidth source of truly random numbers.
> To accomplish this, I set up OpenBSD on a board with a (Soekris) Hifn 7955
> accelerator card, but the rate I'm getting by reading out of /dev/srandom
> is pretty low (200B/s).  However, this has to be coming from the card,
> because the machine has no other reasonable source of entropy other than
> the network: no hard drive, no keyboard, etc.
>
> Now, unless the card's specs are deceptive, its random number generator
> must support a higher rate than this: it claims 70 1024-bit Diffie-Hellman
> key exchanges per second, and each such key exchange requires a full
> 1024-bit random number, which comes out to 8.8kB/s.  The minimum data rate
> for my application is about 1k/s, and I would strongly prefer not to use a
> PRNG.
>
> Is there a more direct way to query the RNG?  random(4) claims that the
> RNG is not mapped directly to a device (/dev/random is not currently
> implemented), but rather that it periodically refreshes the system entropy
> pool.  Is there a way to force this to occur more often, or to transfer
> more data?  Or do the numbers lie, and I'm getting all the data I can?
>
> Thanks for your time,
> Mike Hamburg
>
> P.S. I'm looking at different sources of random numbers, and cost and
> integration are important factors.  Would an AMD Geode LX or VIA C3 or C7
> processor's on-board RNG provide a significantly higher data rate than
> a Soekris card, at a comparable quality?
>

What about taking a cord that's plugged into the sound card port and
microphone port, and reading in from the microphone? I've heard that
is a pretty good source of randomness (all that annoying feedback),
although I may be completely wrong, feel free to correct me if I am.

Jason

Reply | Threaded
Open this post in threaded view
|

Re: Hardware RNG speed

Michael Alexander Hamburg
In reply to this post by Theo de Raadt
On Mon, 19 Dec 2005, Theo de Raadt wrote:

> Until you can justify actual real scientific reasons why you cannot
> use it, I think you should use arc4random().
>
> And I am entirely serious.  The entire idea in OpenBSD is to have many
> consumers, as this strengthens the source.

Thanks for your comments, but I will attempt to justify why I cannot use
arc4random() or /dev/arandom.

I'm working on Professor Rabin's HyperEncryption project.  The goal is to
create a system for distributing random numbers to form one-time pads such
that even an adversary who can break whatever crypto you happen to have
devised is stopped by other limitations, such as limited storage or
limited access to your data lines (that is, you have several links and the
adversary can monitor some but not all of them).  The idea is to offer a
system which is cheaper and more flexible than quantum cryptography, but
almost as secure (i.e. perfectly, information-theoretically secure with
very high probability in the ideal case, requiring more assumptions for
this ideal case than quantum cryptography, but not requiring a short,
private, dedicated fiber-optic line and $50k worth of hardware on either
end).  Obviously, within these design goals, truly random numbers are
necessary, because a computationally unbounded opponent can break
arc4random().  Such an adversary can break other things, too, so we'll
have to do a whole bunch of other things (turning off SYN cookies comes to
mind), but the random numbers are a more immediate design parameter.

Now, the project isn't in production or anything yet; we have some
prototypes are exploring their design spaces, but a very important
parameter is the cost and data rate of commercially available high-quality
random number generators, and their software support under various
operating systems.  Under a limited-access model, the rate is not too
important (while it adds to the amount of data that can be transmitted and
marginally to its security, it is not essential that the data rate be very
high), but 200B/s is still probably too slow.

An important security and maintenance feature of this system will be
whether it can be engineered cleanly.  OpenBSD is considered a relatively
secure OS, has a wide variety of hardware random number generator support,
and perhaps most importantly is relatively easy to configure minimally on
embedded hardware.  So, we're very interested in supporting it,
particularly on embedded hardware, but we need to know what kind of random
number generators work on it at an acceptable rate.  It looks like this
will probably mean the VIA C3 or C7, but we'd like to give Hifn cards a
shot.  Also, given the terrible performance of the Hifn card, it's not
clear that even the VIA C7 would be faster or whether the drivers are the
rate-limiting step, which is why I'm asking for clarification here.  I
could, of course, write a VIA-specific user-mode RNG driver because their
chips allow that. This is a strong draw to VIA, but OS support would be
preferable.

@Jason Crawford, we have considered and even prototyped sound-card-based
solutions (mostly involving running a simple radio noise source into the
microphone port, which is likely to have less pure-tone noise than your
suggestion), and while they aren't out of the running yet they have two
important problems.  First, it will be more difficult to determine whether
the output of this system is sufficiently random.  We can run FIPS tests
in real time at the rates we're dealing with, but the audio system will
almost certainly not pass this or even come close.  Massaging the data
into a form which is both "white" and sufficiently simple that a breakdown
will be detected is rather difficult.  On the other hand, most hardware
RNGs create noise with only very local biases (in raw mode) which should
be easier to filter out without hiding breakages.  Second, most embedded
boards do not have sound cards, an almost none have microphones.

Thanks a lot,
Mike Hamburg

Reply | Threaded
Open this post in threaded view
|

Re: Hardware RNG speed

J.C. Roberts-2
On Tue, 20 Dec 2005 00:52:13 -0500 (EST), Michael Alexander Hamburg
<[hidden email]> wrote:

>On Mon, 19 Dec 2005, Theo de Raadt wrote:
>
>> Until you can justify actual real scientific reasons why you cannot
>> use it, I think you should use arc4random().
>>
>> And I am entirely serious.  The entire idea in OpenBSD is to have many
>> consumers, as this strengthens the source.
>
>Thanks for your comments, but I will attempt to justify why I cannot use
>arc4random() or /dev/arandom.
>
>I'm working on Professor Rabin's HyperEncryption project.  The goal is to
>create a system for distributing random numbers to form one-time pads such
>that even an adversary who can break whatever crypto you happen to have
>devised is stopped by other limitations, such as limited storage or
>limited access to your data lines (that is, you have several links and the
>adversary can monitor some but not all of them).  The idea is to offer a
>system which is cheaper and more flexible than quantum cryptography, but
>almost as secure (i.e. perfectly, information-theoretically secure with
>very high probability in the ideal case, requiring more assumptions for
>this ideal case than quantum cryptography, but not requiring a short,
>private, dedicated fiber-optic line and $50k worth of hardware on either
>end).  Obviously, within these design goals, truly random numbers are
>necessary, because a computationally unbounded opponent can break
>arc4random().  Such an adversary can break other things, too, so we'll
>have to do a whole bunch of other things (turning off SYN cookies comes to
>mind), but the random numbers are a more immediate design parameter.
>
>Now, the project isn't in production or anything yet; we have some
>prototypes are exploring their design spaces, but a very important
>parameter is the cost and data rate of commercially available high-quality
>random number generators, and their software support under various
>operating systems.  Under a limited-access model, the rate is not too
>important (while it adds to the amount of data that can be transmitted and
>marginally to its security, it is not essential that the data rate be very
>high), but 200B/s is still probably too slow.
>
>An important security and maintenance feature of this system will be
>whether it can be engineered cleanly.  OpenBSD is considered a relatively
>secure OS, has a wide variety of hardware random number generator support,
>and perhaps most importantly is relatively easy to configure minimally on
>embedded hardware.  So, we're very interested in supporting it,
>particularly on embedded hardware, but we need to know what kind of random
>number generators work on it at an acceptable rate.  It looks like this
>will probably mean the VIA C3 or C7, but we'd like to give Hifn cards a
>shot.  Also, given the terrible performance of the Hifn card, it's not
>clear that even the VIA C7 would be faster or whether the drivers are the
>rate-limiting step, which is why I'm asking for clarification here.  I
>could, of course, write a VIA-specific user-mode RNG driver because their
>chips allow that. This is a strong draw to VIA, but OS support would be
>preferable.
>
>@Jason Crawford, we have considered and even prototyped sound-card-based
>solutions (mostly involving running a simple radio noise source into the
>microphone port, which is likely to have less pure-tone noise than your
>suggestion), and while they aren't out of the running yet they have two
>important problems.  First, it will be more difficult to determine whether
>the output of this system is sufficiently random.  We can run FIPS tests
>in real time at the rates we're dealing with, but the audio system will
>almost certainly not pass this or even come close.  Massaging the data
>into a form which is both "white" and sufficiently simple that a breakdown
>will be detected is rather difficult.  On the other hand, most hardware
>RNGs create noise with only very local biases (in raw mode) which should
>be easier to filter out without hiding breakages.  Second, most embedded
>boards do not have sound cards, an almost none have microphones.
>
>Thanks a lot,
>Mike Hamburg

Michael,

The best thing you can do is call HiFn and discuss your design
requirements with them rather than trying to guess what the
throughput/rate is for their products. The guy you want to talk to is
probably Russell Dietz (RDietz<AT>hifn.com) VP of Engineering (cc'd). I
once met him for lunch to discuss opening up documentation.

Though HiFn doesn't quite understand the importance of making their docs
freely available without EULAs and legal click-through hoops so OpenBSD
and other open source projects can properly develop drivers, none the
less, the folks working at HiFn are still very nice people.

Kind Regards,
JCR

Reply | Threaded
Open this post in threaded view
|

Re: Hardware RNG speed

Jack Bates
In reply to this post by Michael Alexander Hamburg
> Hello to the list,
>
> ...I set up OpenBSD on a board with a (Soekris) Hifn 7955
> accelerator card, but the rate I'm getting by reading out of /dev/srandom
> is pretty low (200B/s).

I am happily using VIA C3s for a project that requires high-quality
entropy.  In the industry I'm involved in, hardware random is de-rigeur.
The VIA C3, using /dev/srandom, gives me somewhere right around 6KB/s.  I
was hoping for a higher rate, but we just ended up using multiple machines
as a network random-number service (also yields fault-tolerance).

In doing reading (but not of the acutal code), I remember having the
distinct impression that /dev/srandom uses MD5 to "cook" the actual stream
generated by the C3's on-die HRNG.  You have to figure that it is
compressing the stream.  You may wish to look closely at the device driver
code.  There is quite a bit of very good data about the C3's HRNG
available via google.  One analysis of this HRNG made it clear that
"cooking" may be redundant, given the right settings in the driver.  I
made the decision that the developers know what they're up to and left it
at that.

Hope this is helpful.

--
Jack Bates
Venice, CA, USA
I play Texas Hold'Em at http://www.fulltiltpoker.com

Reply | Threaded
Open this post in threaded view
|

Re: Hardware RNG speed

RedShift
In reply to this post by Michael Alexander Hamburg
I tought one of the new features of the Intel Pentium 4, was it's new
real hardware-based random number generator, I remember reading about it.

Also take a look at this:
http://www.irisa.fr/caps/projects/hipsor/HAVEGE1.0.html

If you need alot of random numbers in a short time, you are looking for
a pseudo-random device.

Michael Alexander Hamburg wrote:

> Hello to the list,
>
> I'm working on a cryptography project, and one of the things the project
> requires is a moderately high-bandwidth source of truly random numbers.
> To accomplish this, I set up OpenBSD on a board with a (Soekris) Hifn 7955
> accelerator card, but the rate I'm getting by reading out of /dev/srandom
> is pretty low (200B/s).  However, this has to be coming from the card,
> because the machine has no other reasonable source of entropy other than
> the network: no hard drive, no keyboard, etc.
>
> Now, unless the card's specs are deceptive, its random number generator
> must support a higher rate than this: it claims 70 1024-bit Diffie-Hellman
> key exchanges per second, and each such key exchange requires a full
> 1024-bit random number, which comes out to 8.8kB/s.  The minimum data rate
> for my application is about 1k/s, and I would strongly prefer not to use a
> PRNG.
>
> Is there a more direct way to query the RNG?  random(4) claims that the
> RNG is not mapped directly to a device (/dev/random is not currently
> implemented), but rather that it periodically refreshes the system entropy
> pool.  Is there a way to force this to occur more often, or to transfer
> more data?  Or do the numbers lie, and I'm getting all the data I can?
>
> Thanks for your time,
> Mike Hamburg
>
> P.S. I'm looking at different sources of random numbers, and cost and
> integration are important factors.  Would an AMD Geode LX or VIA C3 or C7
> processor's on-board RNG provide a significantly higher data rate than
> a Soekris card, at a comparable quality?