Hi Holger,
On Thu, Sep 28, 2017 at 12:04:04PM +0800, Holger Freyther wrote:
On 27. Sep
2017, at 19:57, Harald Welte <laforge(a)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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)