prng change feedback

Hello, Apologies in advance for not responding to the relevant thread/message IDs. First time poster, long time reader. Reviewing the relevant email thread about "randomness of identifiers" and the design in the proposed changes [0] by Max, it seems that the patch is reasonable with one or two exceptions. Using OpenSSL is neither necessary, nor sufficient. My understanding is that it brings other restrictions on the use of the RNG, the state of the process, as well as a history of serious security concerns. There are a number of OpenSSL forks such as LibreSSL that seem to be addressing memory safety which might be a better choice. Many user space PRNGs now use getrandom() internally with added complexity in user space which does not seem strictly necessary. If the system RNG is properly seeded at boot, getrandom() should not block at any later point in the system's lifetime. After Nadia Heninger's work[1] attacking the Linux PRNG, the kernel team greatly improved the state of the kernel's RNG/RNG interfaces. If the system RNG is not properly seeded, it is game over. Systems running OpenBSC need to have cryptographically secure source of random numbers. If a user space cryptographic library really is required, it would probably be better to use NaCL [2] which is a well designed library for cryptography. It considers many cryptographic concerns such as various side channel attacks and properly handles each concern in a systematic manner. OpenSSL and its family do not seem to have been so carefully designed. There was recently an interesting design posted [3] by djb about the design of "Fast-key-erasure random-number generators" which sounds exactly like what is desired for this use case. It should be extremely easy to implement. Still, the use of getrandom() without re-seeding is probably necessary and should also be sufficient even for non GNU/Linux systems. Returning to Max's patch: [4] - A lack of a good random number generator should be a hard build/runtime failure. [5] - GNU_TLS is suggested and on the mailing list, OpenSSL, neither seems to be needed. Using glibc interface is less complicated than a full user space RNG. Has anyone reviewed it? Can it fail? If so, how does it fail? It is simple enough that intuitively it should be safe. Using the system call directly should ensure the guarantees of the API are met without any issues. The issue of re-seeding [6] is also one worth re-considering. One lesson learned from various problems with TLS is worth considering here as well: it should be secure to expose random outputs from the (P)RNG and still, it is better to _never_ expose random outputs directly to the network or to an attacker. A simple design for that is simply to hash or encrypt random bytes as djb suggests in his [3] design. Raw PRNG bytes may allow an attacker to break your PRNG as was the case with ExtendedRandom and DualEC [7]. The Debian OpenSSL case [8] is also informative, though of a completely different class of worst case failures, one hopes. Regarding the conclusion of the reviewer: merging Max's code while removing the rand() failure mode would be a net improvement for OpenBSC. The build should fail without getrandom(). Is there any system where this is an expected failure mode? Anything more complex probably deserves a design discussion with a well defined threat model for a given system. Happy Hacking, RS As an aside: If for some reason there is no cryptographically secure hardware RNG on the OpenBSC system, one wonders if it might be of interest to use the available RF interfaces as part of a design for such an RNG. There would be concerns about adversarial control of inputs, of course. It is also reasonable to try to have multiple sources of entropy, especially if the only hardware RNG device is one that isn't verifiable by end users such as RDRAND [9]. [0] https://gerrit.osmocom.org/#/c/1526 [1] https://crypto.stanford.edu/RealWorldCrypto/slides/nadia.pdf [2] https://nacl.cr.yp.to/features.html [3] https://blog.cr.yp.to/20170723-random.html [4] https://gerrit.osmocom.org/#/c/1526/8/utils/osmo-auc-gen.c [5] https://gerrit.osmocom.org/#/c/1526/8//COMMIT_MSG [6] https://blog.cr.yp.to/20140205-entropy.html [7] https://en.wikipedia.org/wiki/Bullrun_%28decryption_program%29 [8] https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-opens… [9] https://en.wikipedia.org/wiki/RdRand#Reception