看板FB_security
標 題Re: Speed and security of /dev/urandom
發信站NCTU CS FreeBSD Server (Fri Jul 18 15:26:01 2014)
轉信站ptt!csnews.cs.nctu!news.cednctu!FreeBSD.cs.nctu!.POSTED!freebsd.org!ow
On Jul 17, 2014, at 4:41 PM, Steven Chamberlain <
[email protected]> wrote:
> Hi,
>
> FreeBSD is as far as I know, quite unique in using Yarrow to provide a
> nice, fast CSPRNG for /dev/urandom
>
> But OpenSSL, LibreSSL, OpenSSH, and various reimplementations of
> arc4random(), don't directly use it. They typically take only ~128 bits
> from /dev/urandom or through other means, to seed a stream cipher, then
> return the output of that. I understand why Linux, even OpenBSD must do
> that. Good-quality random bits from the kernel are scarce, so they
> *must* be stretched somehow.
>
> But isn't that essentially what Yarrow does already in FreeBSD?
Yes, for many values of "essentially". This is a discussion that always ends in a rathole.
> Is there a good reason arc4random_buf() can't take bytes directly from
> /dev/urandom or sysctl KERN_ARND? Therefore no longer needing to seed
> first, periodically reseed, or use any stream cipher?
The "good reason" is the same as above: doing so would cause so much discussion and animosity that it is not worth doing.
>
> There are a few reasons I mention it now:
>
> * arc4random relies on the stream cipher being cryptographically strong
> between reseeds, or else you could guess previous/later output. FreeBSD
> still uses RC4 for arc4random, and that seems increasingly risky;
> OpenBSD moved recently to ChaCha-20, but who knows if even that will
> prove to be safe in the longer term?
>
> * after seeding, some arc4random implementations completely forget to
> reseed after the process forks - the same 'random' stream of bytes could
> occur twice, with security implications
>
> * LibreSSL tried to detect forking, and to reseed automatically, but
> Andrew Ayer showed a corner-case where that still didn't work as
> expected (CVE-2014-2970)
>
> * some arc4random implementations might not be thread-safe
>
> * (re)seeding can fail sometimes (fd's exhausted reading /dev/urandom,
> or that is missing in a chroot; even a sysctl might return an error
> code); OpenSSL and LibreSSL each have 'scary' ways to try to gather
> entropy in userland as a fallback, especially for Linux; FreeBSD and
> OpenBSD may have better expectations that the sysctl will work, and
> maybe raise SIGKILL otherwise
>
> So I wonder, could a simplified arc4random for FreeBSD use Yarrow
> directly, to avoid making any of these sorts of mistakes we've seen?
Yes, it "could". Whether it "should" is another question on a different layer.
>
> (There's also the benefit that having many readers from a single
> pseudorandom stream, adds an additional kind of randomness to its output).
How does having an additional *reader* add additional bits?
> This is obviously a complex issue, and some of it will be subjective.
> But I welcome your comments. Thanks!
Subjective wins.
--Paul Hoffman
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "
[email protected]"