10:46 p.m.
Is there an approved way to increase the speed at which the random pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ (IPv6-only)
11:55 a.m.
On Sat, Aug 21, 2010 at 08:46:24PM -0700, Wolfgang S. Rupprecht wrote:
Is there an approved way to increase the speed at which the random pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
Newer Fedora includes rng-utils / rng-tools (it changed names
recently) that can use a system's TPM (Trusted Platform Module), which
includes a hardware PRNG. rngd can be run as a daemon to get random
numbers from the TPM and feed them into the kernel's entropy pool, for
use by /dev/random.
My Dell servers use this. :-)
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
12:11 a.m.
On Sun, 2010-08-22 at 17:46 +0200, Roberto Ragusa wrote:
As for 1) there are hardware generators based on physical
phenomenons
(from electronic noise to nuclear decay). I would suggest you to use
an audio input sampling some noise (fan noise). The ambient noise
in addition to the electrical noise will be a good entropy source
if you sample at 48000Hz/16bits. Another opportunity is a webcam
(pointed to a fan, blinking LEDs, or a window with wind moving leaves
and clouds...) or an analogic TV acquisition board (not tuned).
I would think a fan might make a regular noise (motor, air buffeting),
not to mention that putting a microphone directly into an air path can
wreck it. A simple solution might be to connect to an analogue tv tuner
or radio tuner off-station, to get the (almost) white noise from it.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
11:15 a.m.
On 08/22/2010 02:47 AM, Wolfgang S. Rupprecht wrote:
Thomas Cameron<thomas.cameron(a)camerontech.com> writes:
> I've always heard that you can get faster random numbers by generating a
> lot of interrupts. I usually do something like run
> /etc/cron.daily/mlocate to generate a lot of disk activity.
I noticed that things speed up quite a bit if I move the mouse in
circles for 10 minutes. The Linux kernel sure makes me work for my
random numbers. ;-)
> And, as I said earlier, depending on how random you want your numbers to
> be, you might consider using /dev/urandom, which is a pseudo-random
> number generator and is a lot faster than /dev/random.
I'm a bit wary of urandom since it will cut down on the search space for
my key. If I need to wait a few days for my 28 keys to be crunched, I'd
rather just wait.
It's a trade-off, I guess. I don't do anything that is so security
sensitive that I have to have that random a number. For me, if I need
random I can use the pseudo-random device and I know that it's "good
enough."
What are you doing that is worth waiting a month for? Or would you have
to kill us if you told us? ;-)
10:46 a.m.
Wolfgang S. Rupprecht wrote:
Is there an approved way to increase the speed at which the random
pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
You need two things:
1) an entropy source
2) a program to feed entropy to the kernel
As for 1) there are hardware generators based on physical phenomenons
(from electronic noise to nuclear decay). I would suggest you to use
an audio input sampling some noise (fan noise). The ambient noise
in addition to the electrical noise will be a good entropy source
if you sample at 48000Hz/16bits. Another opportunity is a webcam
(pointed to a fan, blinking LEDs, or a window with wind moving leaves
and clouds...) or an analogic TV acquisition board (not tuned).
If you take this data and write it into /dev/random, the entropy pool
gets cryptographically messed up.
But the entropy count will not go up.
You need a tool issuing a specific ioctl to do that.
Maybe it already exists, if not, it should be just a few lines of C.
See:
http://en.wikipedia.org/wiki//dev/random
Be very conservative with your entropy count (for example: for 1 second
of audio, just add 100 bits). I just did a quick test with ambient noise
and gzip is almost unable to compress down what I've sampled. That is a
sign that there is a good quantity of entropy.
Even at these paranoia levels, you will cut down the 3 hours a lot.
--
Roberto Ragusa mail at robertoragusa.it
2:57 a.m.
On Sun, 2010-08-22 at 00:47 -0700, Wolfgang S. Rupprecht wrote:
I noticed that things speed up quite a bit if I move the mouse in
circles for 10 minutes.
But you're also doing something predicatable and repetetive -- moving
your mouse in circles for 10 minutes.
I'm a bit wary of urandom since it will cut down on the search space
for
my key. If I need to wait a few days for my 28 keys to be crunched,
I'd
rather just wait.
I suspect that your repetetive circular mouse movements have already
reduced the randomness of the numbers you are generating so
using /dev/urandom may give you similar results with less effort on your
part.
--
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com
2:54 a.m.
Tim <ignored_mailbox(a)yahoo.com.au> writes:
On Sat, 2010-08-21 at 23:43 -0500, Thomas Cameron wrote:
> I've always heard that you can get faster random numbers by generating
> a lot of interrupts. I usually do something like
> run /etc/cron.daily/mlocate to generate a lot of disk activity.
I've always wondered whether that would provide it with real random
seeding, or seeding with a pattern that might be determinable. After
all, you're basing it on the disk contents.
Now that you mention it, I wonder how that works too.
The inter-interupt timing for the disk will probably also be quite
biased. Interrupts that come at a one per sector rate will probably
have strong spikes in their probability functions for "(rotation-time /
number-of-sectors-per-track)". Even with disk zones, there probably
won't be that many different sectors-per-track values.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ (IPv6-only)
2:47 a.m.
Thomas Cameron <thomas.cameron(a)camerontech.com> writes:
I've always heard that you can get faster random numbers by
generating a
lot of interrupts. I usually do something like run
/etc/cron.daily/mlocate to generate a lot of disk activity.
I noticed that things speed up quite a bit if I move the mouse in
circles for 10 minutes. The Linux kernel sure makes me work for my
random numbers. ;-)
And, as I said earlier, depending on how random you want your numbers
to
be, you might consider using /dev/urandom, which is a pseudo-random
number generator and is a lot faster than /dev/random.
I'm a bit wary of urandom since it will cut down on the search space for
my key. If I need to wait a few days for my 28 keys to be crunched, I'd
rather just wait.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ (IPv6-only)
2 a.m.
On Sat, 2010-08-21 at 23:43 -0500, Thomas Cameron wrote:
I've always heard that you can get faster random numbers by
generating
a lot of interrupts. I usually do something like
run /etc/cron.daily/mlocate to generate a lot of disk activity.
I've always wondered whether that would provide it with real random
seeding, or seeding with a pattern that might be determinable. After
all, you're basing it on the disk contents.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
11:43 p.m.
On 08/21/2010 10:46 PM, Wolfgang S. Rupprecht wrote:
Is there an approved way to increase the speed at which the random pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
-wolfgang
Sorry I was way too quick on the previous.
I've always heard that you can get faster random numbers by generating a
lot of interrupts. I usually do something like run
/etc/cron.daily/mlocate to generate a lot of disk activity.
And, as I said earlier, depending on how random you want your numbers to
be, you might consider using /dev/urandom, which is a pseudo-random
number generator and is a lot faster than /dev/random.
11:29 p.m.
On 08/21/2010 10:46 PM, Wolfgang S. Rupprecht wrote:
Is there an approved way to increase the speed at which the random pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
/dev/urandom is a lot faster.
6:21 p.m.
2010/8/22 Thomas Cameron <thomas.cameron(a)camerontech.com>:
On 08/21/2010 10:46 PM, Wolfgang S. Rupprecht wrote:
>
> Is there an approved way to increase the speed at which the random pool
> for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
> keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
> machines seem to have random number hardware built in (perhaps also
> AMD???) Is there a way to funnel this into the entropy pool?
move your mouse e.g. or cause system activity.
/dev/urandom is a lot faster.
it shouldnt be used for anything security relevant like using keys though.
kind regards rudolf kastl
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
4:59 p.m.
Wolfgang S. Rupprecht wrote:
Bill Davidsen <davidsen(a)tmr.com> writes:
> Wolfgang S. Rupprecht wrote:
>> Is there an approved way to increase the speed at which the random pool
>> for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
>> keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
>> machines seem to have random number hardware built in (perhaps also
>> AMD???) Is there a way to funnel this into the entropy pool?
>>
> To be honest, I thought the data from the TCO random generator was funneled in
> already. That's what the "intel-rng" module does.
>
> Current kernel built with:
> CONFIG_HW_RANDOM=y
> CONFIG_HW_RANDOM_TIMERIOMEM=m
> CONFIG_HW_RANDOM_INTEL=m
> CONFIG_HW_RANDOM_AMD=m
> CONFIG_HW_RANDOM_GEODE=m
> CONFIG_HW_RANDOM_VIA=m
> CONFIG_HW_RANDOM_VIRTIO=m
Thanks. That gave me a few good strings to google for.
> If your CPU has the hardware the module should be loaded, but you can
> check with "lsmod | grep rng" to be sure, or load manually to
> test. Also virtio_rng might be useful. You might have to load by hand
> to test, then config to load by default if you want.
It turns out my (2 year old) AMD Phenom 9350e Quad-Core doesn't seem to
have that module loaded. In fact, googling for "AMD hardware random
number generator" got me a few hits of folks running an ms-windows tool
on similar processors and one of the flags checked was for the hardware
rng, which always seemed to be "not supported". I guess the modern CPU
really don't have that hardware any more. How strange (and sad!).
I haven't looked into what virtio-rng does, but it does load on anything I can
quickly test, and I doubt it will make your number any worse.
There are number of cheap USB rng units around which are supported, I just read
about one in Rich Jones' fine blog,
http://rwmj.wordpress.com/2010/08/04/usb-hardware-random-number-generator/
which will probably get you started. His analysis is worth reading if only to
see that some people still have pride in their product.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
3:56 p.m.
Thomas Cameron <thomas.cameron(a)camerontech.com> writes:
What are you doing that is worth waiting a month for? Or would you
have
to kill us if you told us? ;-)
;-)
No, nothing too exciting. I'm just trying to secure my DNS information
and since the key is very public (it is published in DNS itself) I
figured I should really generate it the proper way with a strong random
number generator. (I have a bunch of zones and am publishing some spare
keys, so the keycount adds up quickly.) There isn't much of a downside
to an attacker breaking the key, other than bragging rights and being
able to spoof DNS responses. (Big deal. Someone will get the wrong IP
address or hostname if the happens.)
On the other hand, I've noticed the slow problom with key generation
whenever I update my ssh keys or my ssl keys. If I botch the ssl key,
spammers could send spam via my mail server. If I botch the ssh key
attackers could log in here.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ (IPv6-only)
3:48 p.m.
Bill Davidsen <davidsen(a)tmr.com> writes:
Wolfgang S. Rupprecht wrote:
> Is there an approved way to increase the speed at which the random pool
> for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
> keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
> machines seem to have random number hardware built in (perhaps also
> AMD???) Is there a way to funnel this into the entropy pool?
>
To be honest, I thought the data from the TCO random generator was funneled in
already. That's what the "intel-rng" module does.
Current kernel built with:
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
Thanks. That gave me a few good strings to google for.
If your CPU has the hardware the module should be loaded, but you
can
check with "lsmod | grep rng" to be sure, or load manually to
test. Also virtio_rng might be useful. You might have to load by hand
to test, then config to load by default if you want.
It turns out my (2 year old) AMD Phenom 9350e Quad-Core doesn't seem to
have that module loaded. In fact, googling for "AMD hardware random
number generator" got me a few hits of folks running an ms-windows tool
on similar processors and one of the flags checked was for the hardware
rng, which always seemed to be "not supported". I guess the modern CPU
really don't have that hardware any more. How strange (and sad!).
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ (IPv6-only)
5:12 a.m.
On 08/22/2010 04:46 AM, Wolfgang S. Rupprecht wrote:
Is there an approved way to increase the speed at which the random pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
-wolfgang
If /dev/urandom doesn't provide high enough quality entropy for your
uses you could consider investing in an entropy key:
http://www.entropykey.co.uk/
They're very cheap - around $30-$60 depending on the number you're
buying and have been designed (by a very nice bunch of engineers! ;) for
exactly the problem you're trying to solve.
Very useful for systems that lack any other hardware rng but require a
constant source of good quality entropy.
Regards,
Bryn.
2:34 p.m.
Wolfgang S. Rupprecht wrote:
Is there an approved way to increase the speed at which the random
pool
for /dev/random fills up? I'm playig with dnssec and getnerating 2k rsa
keys is taking up to 3 hours. I've been googling a bit and Intel x86_64
machines seem to have random number hardware built in (perhaps also
AMD???) Is there a way to funnel this into the entropy pool?
To be honest, I thought the data from the TCO random generator was funneled in
already. That's what the "intel-rng" module does.
Current kernel built with:
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
If your CPU has the hardware the module should be loaded, but you can check with
"lsmod | grep rng" to be sure, or load manually to test. Also virtio_rng might
be useful. You might have to load by hand to test, then config to load by
default if you want.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
3:58 p.m.
"Bryn M. Reeves" <bmr(a)redhat.com> writes:
If /dev/urandom doesn't provide high enough quality entropy for
your
uses you could consider investing in an entropy key:
http://www.entropykey.co.uk/
Thanks! I didn't know hardware RNG's were available this cheaply. This
is a very interesting idea!
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ (IPv6-only)
5013
days inactive
5017
days old
18 comments
10 participants
participants (10)
-
Bill Davidsen -
Bryn M. Reeves -
Chris Smart -
Frank Cox -
Matt Domsch -
Roberto Ragusa -
Rudolf Kastl -
thomas cameron -
Tim -
Wolfgang S. Rupprecht