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.netOn 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