At 11:31 AM 12/1/00 -0800, Geoff wrote:
>Hey there,
>On Thu, 30 Nov 2000, Tom Biggs wrote:
>
> > I started to look over hw_cswift.c to get some idea of
> > what I'll need to do for our engine. ...
> > How *do* the PCKS1_SSLeay
> > functions hook to the cswift-specific mod_exp?
>
>Basically, if you look inside the raw software RSA implementations you
>should be able to see what's going on here. Basically, the highest level
>RSA functions are the 4 RSA_[public|private]_[encrypt|decrypt] API
>functions and RSA_[sign|verify] usually delegate their work to
>combinations of those 4 functions unless special flags are set up in the
>method and/or keys (if you don't choose to do this, it doesn't concern
>you). From there, those top-level API functions try to track down the
>RSA_METHOD that should be used with the RSA key that is provided in the
>calls, and passes the data (and work) to the 4 matching handlers in the
>RSA_METHOD. (you can see their implementations in rsa_lib.c)
>
>So, the place you want to look for the default software handlers (ie. the
>default RSA_METHOD code) is in crypto/rsa/rsa_eay.c - that's the default
>software "RSA_METHOD". The current implementation of those four functions
>pass work onto 2 other functions inside the RSA_METHOD - namely
>rsa_mod_exp() and the even lower-level bn_mod_exp(). The CryptoSwift and
>nCipher support avoids reimplementing the 4 top-level functions. All it
>needs to do to hook all the important public and private key operations
>is; (i) implement the 2 lower-level handlers, (ii) ensure the RSA's flags
>are set up appropriately so certain strange optimisations and things don't
>confuse the normal flow of operation, and (iii) steal the 4 top-level
>handlers from the software method. :-) In other words, it virtually copies
>the 4 top-level software handlers, but replaces the "real work" handlers
>with the hardware-specific versions.
Thanks much for taking the time to walk me through that.
Now let me repeat it to see if I've got it straight.
The ENGINE code for a given cryptacclerator will provide complete
replacement RSA_METHOD method structures. However they
don't (really need to) do all the RSA specific stuff, but rather
they simply replicate pointers to the existing RSA software routines.
Then function pointers to two of the lower-level routines that are
usually done in software are replaced by pointers to two routines
that wrap around the hardware-acclerated math. Those routines
may perform some actions in software specific to the algorithm
variant, massage the data and stuff it into the HW, get it back
and bin2bn it back to OpenSSL format. To use this ENGINE
RSA_METHOD it just gets substituted in for the existing RSA_METHOD
pointer, I assume. You wrote "those top-level API functions try to track
down the RSA_METHOD that should be used with the RSA key that is
provided in the calls". I'm not sure I follow, is the RSA_METHOD
looked up on the fly based on the type of key used? (I guess
that watching the key exchange work in gdb would let me
see how that part works, though I don't have an accelerator
card to see how the ENGINE part works.)
I'm also assuming that all of the above goes for DH and DSA too
in approximately the same way...?
While I've got your attention, is the Chinese Remainder Theorem
version of modexp used for fundamentally different purposes than
the standard modexp? (my maths skills are weak.) From my
reading I had assumed that modexpCRT was just an optimized
way of doing it in software.
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
Tom Biggs
'89 FJ1200 DoD #1146
"The whole aim of practical politics is to keep the populace alarmed -
and hence clamorous to be led to safety - by menacing it with an endless
series of hobgoblins, all of them imaginary." -- H.L. Mencken
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
