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/.
Harald Welte laforge at gnumonks.orgHi Holger,
On Thu, Sep 28, 2017 at 12:04:04PM +0800, Holger Freyther wrote:
> > On 27. Sep 2017, at 19:57, Harald Welte <laforge at gnumonks.org> wrote:
> >
>
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
> > like rand() or any other pseudo-random generator of significantly large
> > period is sufficient *if* it is seeded by a non-predictable value. So
> > something like seeding with getrandom() result should be fine?
>
> GLIBC rand() maybe but "any other" not. E.g. if it is a Mersenne Twister
> than observing ~624 TMSIs could be enough to predict past and future state.
thanks for your input.
> Picking something like RAND_bytes of OpenSSL for TMSIs seems to be the
> best way. It will re-seed itself (and we are not forking).
Ok, then let's do that.
> If the OpenSSL dependency is too bad (license compatibility, the move to the Apache license
> could help us here for GPLv3+ software)
Yes, the new apache-style license makes this less of a headache.
So then we conclude for now:
* TMSIs and other temp identifiers: openssl RAND_bytes()
* random challenges for authentication: also RAND_bytes, or getrandom()?
* secret key generation (which we don't implement, so far: ?
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)