On Mon, May 05, 2014, Kurt Roeckx wrote: > On Sun, May 04, 2014 at 06:07:23PM -0400, Geoffrey Thorpe wrote: > > It's lazy-initialisation, so the context-setting (which is used in RSA and > > DSA, not just DH) occurs the first time an operation is attempted on the > > key. (Well, the first time an operation that needs to use the given > > montgomery context within that key, I mean.) It's not that the two threads > > "need to keep initialising it", it only gets initialised once, it's a > > question of how to handle the case where threads are racing to be the one > > that does the first-time initialisation. > > > > The current code simply serialises all threads that are trying to > > initialise previously-uninitialised montgomery contexts, forcing them to > > run one after another. And the math work is done while the lock is held. > > The problem is that this lock isn't specific to the key or montgomery > > context itself, it's global, so it serialises threads even if they're > > working on completely unrelated keys and data structures! > > > > Does that clear it up? Or am I misunderstanding something? > > It makes it more clear what is supposed to be going on. So if I > understand it correctly, they use the same global lock, but it's > actually a different montgomery context and so in the normal case > things wouldn't be thrown away? >
With the current code no, but this is achieved by use of a global lock while the montgomery context is being calculated which results in the lock being held for a non-trivial time which hits performance. The proposed patch (which I think is a good idea) would result in some cases where the context was calculated and discarded but the lock would be acquired for a much shorter time. Normally DH keys in SSL/TLS are single use and only one thread will calculate the montgomery context so it will never be discarded. A further perfomance enhancement would be to calculate and dup the montgomery context in the DH parameters (which are normally fixed) instead of when a key is generated but that's a more complex change. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
