This makes two major semantic changes to Linux's random APIs:
It adds getentropy(..., GRND_INSECURE). This causes getentropy to
always return *something*. There is no guarantee whatsoever that
the result will be cryptographically random or even unique, but the
kernel will give the best quality random output it can. The name is
a big hint: the resulting output is INSECURE.
The purpose of this is to allow programs that genuinely want
best-effort entropy to get it without resorting to /dev/urandom.
Plenty of programs do this because they need to do *something*
during boot and they can't afford to wait. Calling it "INSECURE" is
probably the best we can do to discourage using this API for things
that need security.
This series also removes the blocking pool and makes /dev/random
work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I
believe that Linux's blocking pool has outlived its usefulness.
Linux's CRNG generates output that is good enough to use even for
key generation. The blocking pool is not stronger in any material
way, and keeping it around requires a lot of infrastructure of
dubious value.
This series should not break any existing programs. /dev/urandom is
unchanged. /dev/random will still block just after booting, but it
will block less than it used to. getentropy() with existing flags
will return output that is, for practical purposes, just as strong
as before.
Andy Lutomirski (7):
random: Don't wake crng_init_wait when crng_init == 1
random: Add GRND_INSECURE to return best-effort non-cryptographic
bytes
random: Ignore GRND_RANDOM in getentropy(2)
random: Make /dev/random be almost like /dev/urandom
random: Remove the blocking pool
random: Delete code to pull data into pools
random: Remove kernel.random.read_wakeup_threshold
drivers/char/random.c | 234 ++++--------------------------------
include/uapi/linux/random.h | 4 +-
2 files changed, 27 insertions(+), 211 deletions(-)
--
2.21.0
On Thu, Aug 29, 2019 at 06:11:35PM -0700, Andy Lutomirski wrote:
> This series also removes the blocking pool and makes /dev/random
> work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I
> believe that Linux's blocking pool has outlived its usefulness.
> Linux's CRNG generates output that is good enough to use even for
> key generation. The blocking pool is not stronger in any material
> way, and keeping it around requires a lot of infrastructure of
> dubious value.
It's too late for the 5.4 cycle for a change of this magnitude, and
I'd just as soon let this wait until *after* the LTS kernel gets cut.
The reason for this is because at the moment, there are some PCI
compliance labs who believe that the "true randomness" of /dev/random
is necessary for PCI compliance and so they mandate the use of
/dev/random over /dev/urandom's "cryptographic randomness" for that
reason. A lot of things which are thought to be needed for PCI
compliance that are about as useful as eye of newt and toe of frog,
but nothing says that PCI compliance (and enterprise customer
requirements :-) have to make sense.
It may be that what we might need to really support people (or stupid
compliance labs) who have a fetish for "true randomness" to get a
better interface for hardware random number generators than
/dev/hwrng. Specifically, one which allows for a more sane way of
selecting which hardware random number generator to use if there are
multiple available, and also one where we mix in some CRNG as a
whitening step just case the hardware number generator is busted in
some way. (And to fix the issue that at the moment, if someone evil
fakes up a USB device with the USB manufacturer and minor device
number for a ChosKey device that generates a insecure sequence, it
will still get blindly trusted by the kernel without any kind of
authentication of said hardware device.)
That probably means we need to come up with a new interface than
/dev/hwrng, or have some way of configuring /dev/random to use a
hardware RNG device for those people who really care about "true
randomness". The current /dev/hwrng interface and how it is
configured via sysfs is pretty baroque IMO.
- Ted
> On Aug 29, 2019, at 6:49 PM, Theodore Y. Ts'o <[email protected]> wrote:
>
>> On Thu, Aug 29, 2019 at 06:11:35PM -0700, Andy Lutomirski wrote:
>> This series also removes the blocking pool and makes /dev/random
>> work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I
>> believe that Linux's blocking pool has outlived its usefulness.
>> Linux's CRNG generates output that is good enough to use even for
>> key generation. The blocking pool is not stronger in any material
>> way, and keeping it around requires a lot of infrastructure of
>> dubious value.
>
> It's too late for the 5.4 cycle for a change of this magnitude, and
> I'd just as soon let this wait until *after* the LTS kernel gets cut.
> The reason for this is because at the moment, there are some PCI
> compliance labs who believe that the "true randomness" of /dev/random
> is necessary for PCI compliance and so they mandate the use of
> /dev/random over /dev/urandom's "cryptographic randomness" for that
> reason. A lot of things which are thought to be needed for PCI
> compliance that are about as useful as eye of newt and toe of frog,
> but nothing says that PCI compliance (and enterprise customer
> requirements :-) have to make sense.
>
> It may be that what we might need to really support people (or stupid
> compliance labs) who have a fetish for "true randomness" to get a
> better interface for hardware random number generators than
> /dev/hwrng. Specifically, one which allows for a more sane way of
> selecting which hardware random number generator to use if there are
> multiple available, and also one where we mix in some CRNG as a
> whitening step just case the hardware number generator is busted in
> some way. (And to fix the issue that at the moment, if someone evil
> fakes up a USB device with the USB manufacturer and minor device
> number for a ChosKey device that generates a insecure sequence, it
> will still get blindly trusted by the kernel without any kind of
> authentication of said hardware device.)
>
> That probably means we need to come up with a new interface than
> /dev/hwrng, or have some way of configuring /dev/random to use a
> hardware RNG device for those people who really care about "true
> randomness". The current /dev/hwrng interface and how it is
> configured via sysfs is pretty baroque IMO.
>
>
Hmm. Does this really need to be in the kernel? ISTM it should be straightforward to write a little CUSE program that grabs bytes from RDSEED or RDRAND, TPM, ChaosKey (if enabled, with a usb slot selected!), and whatever other sources are requested and, configurable to satisfy whoever actually cares, mixes some or all with a FIPS-compliant, provably-indististinguishable-from-random, definitely not Dual-EC mixer, and spits out the result. And filters it and checks all the sources for credibility, and generally does whatever the user actually needs.
And the really over-the-top auditors can symlink it to /dev/random.
Do the PCI folks actually care that it’s in the kernel?
As an aside, the first two patches could plausibly land before the rest of the series if that seems appropriate.
On Thu 2019-08-29 18:11:35, Andy Lutomirski wrote:
> This makes two major semantic changes to Linux's random APIs:
>
> It adds getentropy(..., GRND_INSECURE). This causes getentropy to
> always return *something*. There is no guarantee whatsoever that
> the result will be cryptographically random or even unique, but the
> kernel will give the best quality random output it can. The name is
> a big hint: the resulting output is INSECURE.
>
> The purpose of this is to allow programs that genuinely want
> best-effort entropy to get it without resorting to /dev/urandom.
> Plenty of programs do this because they need to do *something*
> during boot and they can't afford to wait. Calling it "INSECURE" is
> probably the best we can do to discourage using this API for things
> that need security.
>
> This series also removes the blocking pool and makes /dev/random
> work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I
> believe that Linux's blocking pool has outlived its usefulness.
> Linux's CRNG generates output that is good enough to use even for
> key generation. The blocking pool is not stronger in any material
> way, and keeping it around requires a lot of infrastructure of
> dubious value.
Could you give some more justification? If crng is good enough for
you, you can use /dev/urandom...
are
> This series should not break any existing programs. /dev/urandom is
> unchanged. /dev/random will still block just after booting, but it
> will block less than it used to. getentropy() with existing flags
> will return output that is, for practical purposes, just as strong
> as before.
So what is the exact semantic of /dev/random after your change?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Sep 9, 2019 at 2:42 AM Pavel Machek <[email protected]> wrote:
>
> On Thu 2019-08-29 18:11:35, Andy Lutomirski wrote:
> > This makes two major semantic changes to Linux's random APIs:
> >
> > It adds getentropy(..., GRND_INSECURE). This causes getentropy to
> > always return *something*. There is no guarantee whatsoever that
> > the result will be cryptographically random or even unique, but the
> > kernel will give the best quality random output it can. The name is
> > a big hint: the resulting output is INSECURE.
> >
> > The purpose of this is to allow programs that genuinely want
> > best-effort entropy to get it without resorting to /dev/urandom.
> > Plenty of programs do this because they need to do *something*
> > during boot and they can't afford to wait. Calling it "INSECURE" is
> > probably the best we can do to discourage using this API for things
> > that need security.
> >
> > This series also removes the blocking pool and makes /dev/random
> > work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I
> > believe that Linux's blocking pool has outlived its usefulness.
> > Linux's CRNG generates output that is good enough to use even for
> > key generation. The blocking pool is not stronger in any material
> > way, and keeping it around requires a lot of infrastructure of
> > dubious value.
>
> Could you give some more justification? If crng is good enough for
> you, you can use /dev/urandom...
Take a look at the diffstat. The random code is extremely security
sensitive, and it's made considerably more complicated by the need to
support the blocking semantics for /dev/random. My primary argument
is that there is no real reason for the kernel to continue to support
it.
>
>
> are
>
> > This series should not break any existing programs. /dev/urandom is
> > unchanged. /dev/random will still block just after booting, but it
> > will block less than it used to. getentropy() with existing flags
> > will return output that is, for practical purposes, just as strong
> > as before.
>
> So what is the exact semantic of /dev/random after your change?
Reads return immediately if the CRNG is initialized, i.e reads return
immediately if and only if getentropy(..., 0) would succeed.
Otherwise reads block.
--Andy