On Sun, Feb 19, 2017 at 7:17 PM, Niels Möller <[email protected]> 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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
