On Sun, Jul 20, 2014 at 05:25:40PM -0700, Dwayne Litzenberger wrote:
>
> This could still return predictable bytes during early boot, though, right?
Read the suggetsed man page; especially, the version of the man page
in the commit description -v4 version of the patch.
getrandom(2) is a new interface, so I can afford do things differently
from redaing from /dev/urandom. Specifically, it will block until it
is fully initialized, and in GRND_NONBLOCK mode, it will return
EAGAIN.
There have been some people kvetching and whining that this is less
convenient for seeding srand(3), but for non-crypto uses, using
getpid() and time() to seed random(3) or rand(3) is just fine, and if
they really want, they can open /dev/urandom.
> > The system call getrandom() fills the buffer pointed to by buf
> > with up to buflen random bytes which can be used to seed user
> > space random number generators (i.e., DRBG's) or for other
> > cryptographic processes. It should not be used Monte Carlo
> > simulations or for other probabilistic sampling applications.
>
> Aside from poor performance for the offending application, will anything
> actually break if an application ignores this warning and makes heavy
> use of getrandom(2)?
It will be slow, and then the graduate student will whine and complain
and send a bug report. It will cause urandom to pull more heavily on
entropy, and if that means that you are using some kind of hardware
random generator on a laptop, such as tpm-rng, you will burn more
battery, but no, it will not break. This is why the man page says
SHOULD not, and not MUST not. :-)
> As the developer of a userspace crypto library, I can't always prevent
> downstream developers from doing silly things, and many developers
> simply don't understand different "kinds" of random numbers, so I prefer
> to tell them to just use the kernel CSPRNG by default, and to ask for
> help once they run into performance problems. It's not ideal, but it's
> safer than the alternative.[1]
Yes, but the point is that Monte Carlo simulations don't need any kind
crypto guarantees.
> Hm. Is it correct that, in blocking mode, the call is guaranteed either
> to return -EINVAL immediately, or to block until the buffer is
> *completely* populated with buflen bytes? If so, I think a few small
> changes could make this a really nice interface to work with:
>
> * Use blocking mode by default.
Read the -v4 version of the patch. Blocking is now the default.
> * Add a new flag called GRND_PARTIAL (replacing GRND_BLOCK), which
> indicates that the caller is prepared to handle a partial/incomplete
> result.
This is not needed if you are using the preferred use of flags == 0,
and are extracting a sane amount of entropy. For values of buflen <
256 bytes, once urandom pool is initialized, getrandom(buf, buflen, 0)
will not block and will always return the amount of entropy that you
asked for.
But if the user asks for INT_MAX bytes, getrandom(2) must be
interruptible, or else you will end up burning CPU time for a long,
LONG, LONG time. The choice was to either pick some arbitrarily
limit, such as 256, and then return EIO, which is what OpenBSD did. I
decided to simply allow getrandom(2) to be interruptible if buflen >
256.
Similarly, if you use GRND_RANDOM, you are also implicitly agreeing
for what you are calling GRND_PARTIAL semantics, because otherwise,
you could end up blocking for a very long time, with no way to
interrupt a buggy program.
I'd much rather keep things simple, and not add too many extra flags,
especially when certain combination of flags result in a really
unfriendly / insane result.
> * If GRND_PARTIAL is *not* set, just return 0 on success. (This avoids
> all signed-unsigned confusion when buflen > INT_MAX.)
We simply cap any requests for buflen > INT_MAX, and in practice, it
would take so long to generate the requested number of bytes that the
user would want to interrupt the process anyway.
I considered adding a printk to shame any application writer that
tried to ask for more than 256 bytes, but ultimately decided that was
a bit over the top. But in any case, any request anywhere near
INT_MAX bytes is really not anything I'm concerned about. If we do
start seeing evidence for that, I might reconsider and add some kind
of "Warning! The author of [current->comm] is asking for insane
amounts of entropy" printk.
> With those changes, it would be trivial for a userspace library to
> implement a reliable RNG interface as recommended in [2] or [3]:
The userspace library should ideally be integrted into glibc, so it is
fork- and thread- aware, and it should use a proper CRNG, much like
OpenBSD's arcrandom(3). There's been a proposal submitted to the
Austin Group for future standardization in Posix, and I'm all in favor
of something like that.
> P.S. If I had my way, I would also drop GRND_RANDOM. Most software
> won't use it, there's no legacy installed base, and no developer who
> still wants that behavior can legitimately claim to care about RNG
> availability guarantees, IMHO.
GnuPG uses /dev/random when generating long term public keys. So
there are some use cases where I think GRND_RANDOM makes sense. I
agree they are not the normal ones, but they do exist.
> [1] On more than one occasion, I've seen developers use Python's
> standard "random" module to generate IVs. I mean, why not? IVs are
> public, right?
Why are they writing code that needs raw IV's in the first place?
Sounds like a misdesigned crypto library for me, or they were using
low-level crypto when they should have been using a more higher-level
abstraction.
The fundamental problem is that it's impossible to make an interface
be moron-proof because morons are so ingenious. :-) If they are so
misinformed that they are using random(3) to generate IV's, they are
extremely likely to be making other, much more fundamentally wrong
mistakes. The only real solution is to not let them anywhere near
that level of crypto programming, which means you need to have high
level libraries which are so appealing and easy to use that they
aren't tempted to go low level on you...
Originally I thought that the answer was to have a userspace library
interface where you would ask the user to tell you whether they needed
the interface for Monte Carlo simulations, IV's, padding, session
keys, long-term keys, etc. However, the counter argument was that the
morons that would be helped by this explicit statement of need would
likely be making other crypto-implementation mistakes anyway, so it's
not worth it.
The one reamining reason why specifying the usage of the random values
might be useful is if you are in a world where various NIST standards
or some Military- or credit-card-processing imposed standards might
require you to say, using a certified hardware RNG for long-term keys,
but allowed the use of a crypto-based DRBG for session keys (for
example), that's something that could be configured or controlled in a
single location.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
