On Sun, Feb 19, 2017 at 7:17 PM, Niels Möller nisse@lysator.liu.se wrote:
Currently gnutls provides a "central" random generator based on yarrow (for keys) and salsa20 (for nonces) primitives, and it is thread safe by utilizing mutexes over it. An application that has more than 100-200 threads is most likely to spend more time in synchronization rather than the random generator itself. A solution to that would be to provide a thread-local random generator which will work lock-free, at the cost of additional memory per-thread -around 600-700 bytes for the current generator-.
Would it make sense to handle the two cases differently, with a thread-local nonce-generator, but stick to a global key-generator protected by a mutex?
I imagine there are a lot more calls for nonces than for keys?
Certainly. Currently, there is at least a single call for key generation on each established TLS session, meaning that the bottleneck will remain, for the case where multiple threads are used to host multiple sessions - it will be reduced to a single place however -.
For the yarrow reseed logic, I think it may be preferable with a global instance.
If we need yarrow, your recommendation seems to be the right approach. However, another thought it has been bugging me lately, is whether we need yarrow in gnutls. It looks quite suited for something central like /dev/urandom which has several maybe untrusted inputs, but for gnutls which seeds from /dev/urandom (or the equivalent system calls), having a PRNG which concerns itself with manipulation of input may not be adding the security it is perceived to add.
regards, Nikos