prng change feedback

[Max]

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.

-- 

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