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. I got flummoxed
> right away by this comment inside ENGINE_cswift() -
>
> /* We know that the "PKCS1_SSLeay()" functions hook properly
> * to the cswift-specific mod_exp and mod_exp_crt so we use
> * those functions. ...
> */
>
> Just what does that mean? I couldn't find any references
> to the cryptoswift card elsewhere. I've seen some
> conditional compiles for atalla (which presumably
> pre-dated the ENGINE stuff). How *do* the PCKS1_SSLeay
> functions hook to the cswift-specific mod_exp?
> The hw_ncipher() module had the exact same comment
> referring to cswift, and the atalla module had the
> same comment except that it said "atalla" instead
> of "cswift".
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.
> Also, I'm having difficulty seeing the path from the
> higher-level caller of, say, modexp down through
> to the engine methods contained in the engine-specific
> ENGINE structure. And I'm not too clear on how the
> (RSA|DSA|DH)_METHODs defined in the hardware
> are connected in either... Oh, I'll figure it all out
> eventually - but if someone could provide a simple
> summary of how the ENGINE maths supplant the
> built-in software maths routines, and provide a few
> hints on how it all hangs together, I'd be quite happy...
Well, hopefully that provides some guidance. The more important thing is
to understand how the software itself works in the first place - from
there making the step across to how the ENGINE stuff hangs together and
how to use this trickery to hook things minimalistically is quite
straightforward. After all, it was designed to be as transparent a layer
as possible to the existing (software-only) code. It seems the
(understandable) confusion here is to follow the relationships of RSA,
RSA_METHOD, grasp the role of the handlers in the RSA_METHOD, and then
finally to realise how the software implementation in rsa_eay.c is
actually heirachical. Ie. you don't have to reimplement all the handlers
(but you're welcome to if you need that) - but you just need to get the
hooking right.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
