Date: Thu, 20 Sep 2012 08:32:36 +0100 From: Jonathan Anderson <jonathan@FreeBSD.org> To: RW <rwmaillists@googlemail.com> Cc: freebsd-security@FreeBSD.org Subject: Re: Collecting entropy from device_attach() times. Message-ID: <10CD8D9A9ADB484694DE4DCBD9594FAB@FreeBSD.org> In-Reply-To: <20120919214624.2f6682a2@gumby.homeunix.com> References: <20120918211422.GA1400@garage.freebsd.pl> <A8FD98DD94774D00B4E5F78D3174C1B4@gmail.com> <20120919192923.GA1416@garage.freebsd.pl> <CAG5KPzyxSMZ8X4RmEhCHA=dHTLUw5mOUf-oveJtOPx8im3dpeQ@mail.gmail.com> <20120919214624.2f6682a2@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 19 September 2012 at 21:46, RW wrote:
> extra bits may make the difference between secure and insecure
I'm sorry, this may be a bit pedantic, but I have to object to the terms "secure" and "insecure" used without qualification. :) Perhaps you mean "predictable" and "unpredictable"?
Believe it or not, this is a serious point rather than just nit-picking: there are all kinds of things that we might want to do with "random" numbers during boot, but not all of them require unpredictability in the face of an adaptive adversary. When generating a random MAC address (sys/arm/at91/if_ate.c:305), we don't need unpredictability, we just need per-machine uniqueness. When using a random delay to prevent things happening in cyclical lockstep (sys/kern/kern_synch.c:563), we don't even need that: we just need *some* things to get different delay values.
So while cryptographic ("secure") randomness is always sufficient, it's not always necessary, especially in very simple machines that have a hard time harvesting entropy early in the boot process. This is part of why I'd like to see us move to a more descriptive API:
- fuzz_value(range)
- unique_value(range)
- unpredictable_value(range)
or something like that, instead of committing to particular algorithms (arc4random) or (in userspace) telling /dev/random to "get me some random, whatever that happens to mean". The implementation of each of these functions could start with "if I have a properly-initialised PRNG, use that", but for code that doesn't require true unpredictability, it might be good to just carry on booting with only-slightly-random numbers rather than wait for entropy estimates to hit the cryptographic threshold.
But that's a discussion for another (future) thread. :)
Jon
--
Jonathan Anderson
jonathan@FreeBSD.org (mailto:jonathan@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10CD8D9A9ADB484694DE4DCBD9594FAB>