prng change feedback

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

ringsignature at riseup.net ringsignature at riseup.net
Sat Oct 7 09:18:46 UTC 2017


On 2017-10-07 06:30, Harald Welte wrote:
> Hi RS,
> 
> On Fri, Oct 06, 2017 at 08:43:22AM -0700, ringsignature at 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



More information about the OpenBSC mailing list