On 2017-10-06 12:50, Max wrote:
On 06.10.2017 03:23, Harald Welte wrote:
So the conclusion is probably, for now:
* use getrandom() with zero flags for TMSIs and other random identifiers
* use getrandom() with zero flags for RAND challenges
I don't think it's a good idea. It's fine for exploratory programming while
experimenting but in the library which is meant for production use
behavior should be
as predictable as possible.
Using "zero flags" means that the function might or might not block
which pretty-much
guarantees headaches later on when troubleshooting the code which will use it.
Is there any reason that it isn't just called a single time on system
startup? It should never again block after that point in time. A
measurement that might be worth considering is if it blocks, ever, in
practice? At least one of my Debian systems appears to ensure that the
RNG is seeded before it has reached the run level where services run.
Might that be the case here? Might it also be possible to call the
wrapper for getrandom() at library init time as well as later when the
random bytes are needed?
I think we should always opt for "least
surprise" path and use
GRND_NONBLOCK (as in
current patch). That way we'll never block and let the caller handle
errors (if any).
Isn't it more error prone to handle errors and unfilled buffers than to
block a single time? Seems tricky, though I agree that consistent
behavior might be worth the trade off. If GRND_NONBLOCK ensures that no
buffer is ever underfilled, that might be the middle ground that makes
the most sense.
* use getrandom() with GRND_RANDOM flag for
K/OP/OPc/Ki generation
I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both
/dev/random and /dev/urandom are going through the same CSPRNG so I'm
not sure we
gain anything by requiring random instead of urandom.
That is my understanding as well. The key difference is that you were
spot on about the pool being drained very seriously - to the point of
underflowing, thus potentially encountering serious error states. Those
error states might be a 512 byte buffer with only one random byte, for
example.
Happy Hacking,
RS