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/.
Max msuraev at sysmocom.deHi. Thanks for bringing it up. I think some clarifications about the current implementation are required - see below. On 27.09.2017 13:57, Harald Welte wrote: > Using the rather strong entropy pool of /dev/urandom or getrandom() > is apparently not a good choice either: We can exhaust the entropy pool > at whch point we would have to block/wait, which we of course cannot in > our architecture. Note: current implementation available in https://gerrit.osmocom.org/#/c/1526/ will never ever block. It will fallback to insecure rand() if there's not enough entropy in the pool and let caller know about it. This is exactly what the existing code does. > So what do we do? I think we first have to differentiate on the type of > randomness needed. Is it a random identifier like TMSI? Is it a random > challenge used in cryptographic authentication? Is it random data used > for a key? Those require different levels of randomness. I think before adding all this complexity we should first check how realistic the entropy exhaustion in practice? The implementation in https://gerrit.osmocom.org/#/c/1526/ does not allow you to request more than 16 bytes of random data at once. And such requests could not come at arbitrary speed either - attacker have to trigger certain events which would result in random identifier generation. Linux kernel constantly gather entropy. Is it possible for an attacker to exhaust it faster than kernel gathers it? Also, it's important to remember that the consideration above are for "the ideal system we want to build". If we compare it with the current implementation, than https://gerrit.osmocom.org/#/c/1526/ can be merged right away: - it uses secure random data if it's available - it falls back to insecure random generator if not - it gives exactly the same log messages about it as the current code So there are actually 2 questions in here: - can we merge gerrit #1526? - can we do even better? IMHO, the answers are "yeah" and "should we?" :) -- Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte