On 2017-10-07 06:30, Harald Welte wrote:
Hi RS,
On Fri, Oct 06, 2017 at 08:43:22AM -0700, ringsignature(a)riseup.net wrote:
* 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.
I don't think this is an issue. We can actually do blocking reads for
key generation, once we ever do that. The speed of programming SIM
cards is probably invariably slower than the amount of randomness we can
get. That's a one time operation at the time SIM cards are programmed.
That suggests setting GRND_NONBLOCK for all calls except for generation
of SIM card cryptographic keys, I think?
In the latter case, setting a flag of '0' may be appropriate. After
reading one of the latest [0] papers on the robustness of /dev/random, I
think it would be wise to leave GRND_RANDOM out and only use urandom in
a properly seeded state for such keys. That that paper does not inspire
confidence in even that choice, sadly I don't see a better choice.
Happy Hacking,
RS
[0]
https://eprint.iacr.org/2013/338.pdf