At 10:14 AM 9/20/01 -0700, Geoff wrote:
>On Wed, 19 Sep 2001, Tom Biggs wrote:
>
> > I'm wondering how much overlap there might be between _all_ of
> > the modulus values used across all OpenSSL modular exponentiation
> > calls. If there is a good probability that some reasonably-sized
> > set of moduli (plural sp?) are used again and again, I can get
> > increased performance from our hardware by caching values derived
> > from the moduli.
>
>For general "BN_mod_exp[_crt|_mont]" implementations, "not really". You
>could if you want and yes, you will often getting matching modulii (and
>exponents for that matter), but you'd have to use a hash-table as there may
>be a few commonly used keys rather than one.
Yes, I was thinking of a b-tree for fast lookup, but then I realized
that I'd have to age the one-time entries or use some sort of LRU
scheme to purge, then I started thinking about mutexes and other overhead
involved with multi-threading, and then my head started to hurt... ;-)
The main criteria is that the hardware optimization has to save more
time than the software overhead required to take advantage of it!
>Better still is to simply do it at the RSA, DSA, and DH levels (which is
>after all where most of the action will be happening through). Consult the
>"ex_data" functions - you can cache any per-key stuff you like using the
>"ex_data" storage inside each one of those objects. This is also useful for
>converted BIGNUM forms (eg. not recomputing and reallocating BN_bn2bin()
>output every time, etc). If your "cache" is attached to each key, you know
>extremely well that the modulus, exponent, or any other key details won't
>be changing much, if at all. :-)
Ah, Geoff, you're my saviour! This would actually work, and not
add much overhead. Considering the bn2/2bn time saving on multiple
uses of the same key, it might even reduce overhead.
Thanks for the idea.
Of course I will have to actually re-implement the RSA/DSA/DH
higher-level modexps, and with my weak maths, that might prove
to be a disaster. (Currently I mostly rely on hooking the lowest
level bn_mod_exp() function.) Hopefully I can muddle through by
copying and tweaking the EAY stuff.
> > My gut feeling is that even if I maintained a global cache,
> > I wouldn't get too many second hits on the same modulus.
>
>You certainly would. Ditto on the exponents. It's just that it may not be
>just *one* commonly occuring value (or, if you're running a single SSL
>server, you'll probably have one very common modulus and exponent from the
>server's key, but lots of other always-changing values when verifying
>client certificates and/or using EDH cipher-suites). For this sort of
>BIGNUM level cache trickery, you're better to simply build the support into
>a hardware driver
Hmmm, didn't want a lot of memory allocation going on at that level.
>or on the hardware itself.
For a lot of very good reasons, my boss is extremely parsimonious
with hardware registers/RAM. (To begin with, this hardware does a
*whole* lot more than just crypto acceleration.)
>However, at the RSA, DSA (etc)
>structure levels ... you know a *lot* more about what will and won't
>change at run-time.
And I can let OpenSSL keep track of them.
Now I'm off to scratch my head over the *_ex_data functions. They seem
a bit over-complicated but I'm hoping it's just redundant functionality.
Looks like the new() is called before I can do anything useful besides
do my own allocation, since the key data won't be in place, but that's
not a big deal.
Question: If I call (say) RSA_get_ex_new_index() when my ENGINE is
first initialised, will any RSA structures (such as the server's key)
have been created _before_ that time? Will I have to kludge to
retrofit my ex_data into them? Or is the ENGINE pulled in before any
of those RSA structures are created?
Tom Biggs
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
