OK here's may argument. All IMHO. Feel free to pull it to bits at will
:-)
There are some nasty problems with doing things this way.
The simplest is that CryptoAPI base and enhanced CSPs (for RSA
licensing, cost and export licensing reasons I believe) only indirectly
allows access to RSA. That is you cannot use RSA directly to encrypt and
decrypt arbitrary data blocks.
You could in theory replace some of the SSLeay calls which combine
digests and RSA and symmetric encryption and RSA. Some is the operative
word here. There are some variants that SSLeay needs that CryptoAPI
doesn't support.
If that doesn't put you off enough then consider this as well. AFAIK you
can't load arbitrary keys into the symmetric encryption algorithms of
CryptoAPI: they have to go either via a digest or via a key exchange
mechanism. SSLeay needs to do this at various points. Thus you have to
replace digests and symmetric encryption calls with CryptoAPI but only
part of the time...
What this means in practice is that you can't just replace the SSLeay
RSA interface with the CryptoAPI one. You have to replace combined
operations and even then you can't replace them all and there are things
you simply cannot do.
I seem to recall someone mentioning a while ago that alternative CSPs
exist that do support an exposed RSA interface. If this is the case then
things become almost trivial. However EAR probably prevents me from
looking at such things.
Steve.
--
************************************************
* Dr Stephen N. Henson. *
* Freelance Cryptographic Consultant. *
* Email: [EMAIL PROTECTED] *
************************************************
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
