On 06.10.2017 03:23, Harald Welte wrote:
So the conclusion is probably, for now:
- use getrandom() with zero flags for TMSIs and other random identifiers
- use getrandom() with zero flags for RAND challenges
I don't think it's a good idea. It's fine for exploratory programming while experimenting but in the library which is meant for production use behavior should be as predictable as possible.
Using "zero flags" means that the function might or might not block which pretty-much guarantees headaches later on when troubleshooting the code which will use it.
I think we should always opt for "least surprise" path and use GRND_NONBLOCK (as in current patch). That way we'll never block and let the caller handle errors (if any).
- 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.
Also, are we talking about utils/osmo-auc-gen or smth else?
I would go for that, and I believe the current patch under discussion is doing exactly that: use getrandom() if available, and fall back to the raw syscall, if not.
Yepp, that's how it's done.
Further falling back on rand() is probably a bad idea
Removed: it was there only because that's how OpenBSC and other apps have always used it. But if we do not plan to use insecure random anymore than it's not needed.