yarrow random generator
Paul Graphov
I've looked at FreeBSD 8.0 cryptographically secure pseudorandom
numbers generator and have a question. It looks like a bug but I'am
not sure.
In file sys/dev/randomdev.c, function random_read:
if (!random_systat.seeded)
error = (*random_systat.block)(flag);
It blocks until PRNG is seeded. For software random generator implementation
block method looks as follows, sys/dev/randomdev_soft.c:
random_yarrow_block(int flag)
{
int error = 0;
mtx_lock(&random_reseed_mtx);
/* Blocking logic */
while (random_systat.seeded && !error) {
if (flag & O_NONBLOCK)
error = EWOULDBLOCK;
else {
printf("Entropy device is blocking.\n");
error = msleep(&random_systat,
&random_reseed_mtx,
PUSER | PCATCH, "block", 0);
}
}
mtx_unlock(&random_reseed_mtx);
return error;
}
It seems that random_systat.seeded in "while" condition should be negated.
Or it will never block actually, or block erroneously until next reseed
(under very rare
conditions)
Am I right?
Thanks.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
RW
Paul Graphov <gra...@gmail.com> wrote:
> Hello guys,
>
> I've looked at FreeBSD 8.0 cryptographically secure pseudorandom
> numbers generator and have a question. It looks like a bug but I'am
> not sure.
>
> In file sys/dev/randomdev.c, function random_read:
>
> if (!random_systat.seeded)
> error = (*random_systat.block)(flag);
>
> It blocks until PRNG is seeded.
random_systat.seeded is initialized to 1 and it's never set to anything
other than 1
I got impression that blocking was something that seemed like a good
idea at the time, but fell-off half-way through coding. It's not a
good idea to block /dev/random, without a separate urandom.
Paul Graphov
In this case If somebody resets it to zero, some "read" goest to "block" and
before acquiring mutex it is reseeded, setting it to true, block will never
leave the cycle.
2009/12/24 RW <rwmai...@googlemail.com>
Paul Graphov
"seeded" to zero?
SYSCTL_ADD_PROC(&random_clist,
SYSCTL_CHILDREN(random_sys_o),
OID_AUTO, "seeded", CTLTYPE_INT | CTLFLAG_RW,
&random_systat.seeded, 1, random_check_boolean, "I",
"Seeded State");
And also according to Schneier it is a good idea to save state of the PRNG
and restore it on boot to make it
"more seeded".
2009/12/24 Colin Percival <cper...@freebsd.org>
> Hi all,
>
> Looks like there's a bug here, but it doesn't matter since this is dead
> code: .seeded is initialized to 1 and never modified, so we will never
> call into random_yarrow_block.
>
> IIRC this is because there are some places which ask for entropy before
> yarrow is seeded but don't actually need *cryptographic* entropy.
> --
> Colin Percival
> Security Officer, FreeBSD | freebsd.org | The power to serve
> Founder / author, Tarsnap | tarsnap.com | Online backups for the truly
> paranoid
Robert Watson
> And also according to Schneier it is a good idea to save state of the PRNG
> and restore it on boot to make it "more seeded".
In the default configuration, we save some PRNG output every few minutes
(using cron) to a file in /var so that it can be re-injected into Yarrow on
the next boot (done by /etc/rc.d/random).
Robert N M Watson
Computer Laboratory
University of Cambridge
RW
Robert Watson <rwa...@FreeBSD.org> wrote:
> On Thu, 24 Dec 2009, Paul Graphov wrote:
>
> > And also according to Schneier it is a good idea to save state of
> > the PRNG and restore it on boot to make it "more seeded".
>
> In the default configuration, we save some PRNG output every few
> minutes (using cron) to a file in /var so that it can be re-injected
> into Yarrow on the next boot (done by /etc/rc.d/random).
It isn't handled very well though. The files saved by crontab
under /var are loaded a bit late in the boot sequence - after encrypted swap.
The main entropy file is loaded earlier, but immediatly after
ps -fauxww, sysctl -a, etc are dumped into the device, saturating its 4K
of buffer space.
Robert Watson
On Thu, 24 Dec 2009, RW wrote:
>>> And also according to Schneier it is a good idea to save state of the PRNG
>>> and restore it on boot to make it "more seeded".
>>
>> In the default configuration, we save some PRNG output every few minutes
>> (using cron) to a file in /var so that it can be re-injected into Yarrow on
>> the next boot (done by /etc/rc.d/random).
>
> It isn't handled very well though. The files saved by crontab under /var are
> loaded a bit late in the boot sequence - after encrypted swap.
>
> The main entropy file is loaded earlier, but immediatly after ps -fauxww,
> sysctl -a, etc are dumped into the device, saturating its 4K of buffer
> space.
I can't speak to the specific /dev/random design choices here, but I can say
that there is a more general issue with swap being required to get to the
point where you reliably have writable file system access. This is because
fsck can be quite memory-heavy, and so swap is started before fsck is started.
It could well be that the arrival of proper UFS journaling support in the
immediate future allows more agressive reordering of the boot process so that
writable file systems can be assumed much earlier.
I'll point Mark Murray at this thread and see if we can get him to opine some
on the current design choices and any potential changes to address them. I
was interested by your observation that the boot-time dumping of bits into
/dev/random may overflow the buffering -- indeed, it looks like the
rate-controlling in effect for other entropy sources may not be appropriate
for /dev/random.
Robert N M Watson
Computer Laboratory
University of Cambridge
Doug Barton
> I'll point Mark Murray at this thread and see if we can get him to opine
> some on the current design choices and any potential changes to address
> them. I was interested by your observation that the boot-time dumping
> of bits into /dev/random may overflow the buffering --
I was peripherally involved in the introduction of yarrow in the sense
that I wrote most of the rc and periodic stuff for it so I am also
interested in this issue. Rather than speculating about whether it's
overflowing the buffer perhaps a patch can be produced to test this
hypothesis? I can't do it today, but if no one else gets around to it
soon I will give it a look.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
RW
Doug Barton <do...@FreeBSD.org> wrote:
> Robert Watson wrote:
> > I'll point Mark Murray at this thread and see if we can get him to
> > opine some on the current design choices and any potential changes
> > to address them. I was interested by your observation that the
> > boot-time dumping of bits into /dev/random may overflow the
> > buffering --
>
> I was peripherally involved in the introduction of yarrow in the sense
> that I wrote most of the rc and periodic stuff for it so I am also
> interested in this issue. Rather than speculating about whether it's
> overflowing the buffer perhaps a patch can be produced to test this
> hypothesis?
It's not really speculation, the data is broken into 16 byte chunks,
random_harvest_internal() is called to copy each chunk into a buffer
and queue it. If there are 256 or more buffers in the queue
random_harvest_internal() returns without doing anything.
The kernel thread that processes the queues calls
pause("-", hz /10) each time it loops.
A fairly simple solution would be piping all that low-grade entropy
from sysctl and ps etc through sha256, reducing it to 64 bytes.