I attended a meeting at Microsoft the other day at which they described their Crypto API project. As CAPIs go, it's reasonable enough; nothing particularly exciting about it or especially wrong with it (though they don't yet support nonblocking calls to crypto modules). They've defined 23 cryptographic services (establish key, encrypt, etc.) that an application is expected to use for its cryptographic needs. The idea is to hide the crypto details (and keys) from applications, and to make it easy to switch from, say, wimpy export-approved crypto to good crypto just by switching to another DLL at load-time. The cryptography used depends on the crypto modules in use at runtime. The API will be part of the WIN32 interface. The next version of NT (and windows 95, I think), to be released in a few months will support loading ``Cryptographic Service Providers'' (CSPs) that contain the crypto functions that sit below the API. They have (or will have soon) an application development kit to allow you to write code that uses the API, and a CSP development kit to let you write the crypto functions. The interesting part is that they say they've made a deal with the government to allow applications that use the API to be exportable as long as they don't also try to implement crypto on their own. Ordinarily, the government claims that ``crypto with a hole'' (applications that call a crypto API) are just as export-controlled as crypto functions themselves, so this is something of a surprise and would represent considerable forward progress. But, of course, there's a catch. The OS will not load just any old CSP. CSPs have to be signed by Microsoft. The kernel contains a (hardcoded?) 1024 RSA public key that it uses to check the signature when the user tries to load a CSP. If the signature check fails, the CSP won't load. Microsoft says it will sign any CSP from anyone AS LONG AS THEY CERTIFY THAT THEY WILL FOLLOW THE EXPORT RULES. So you can get your CSP signed if you use exportable cryptography or if you agree not to send it outside the US and Canada, etc. But an end user can't just compile crypto code and use it as a CSP, even for his or her own use, without getting it signed by Microsoft first (actually, the CSP development kit does allow this, but it uses a special version of the OS). I'm not sure whether this whole thing is good or bad. One important issue is whether MS will really sign anyone's CSP or whether they will start charging high fees or making business-based decisions on who's CSPs they will allow (with they sign Netscape's CSP, for example). They say they won't even look or keep a copy of your CSP (at my suggestion, they are probably going to change the process so that you send them a hash of your CSP instead of your CSP code when you get the signature). For now they promise to sign CSPs for anyone who returns the export certificate, at no charge. We (Jack Lacy and I) will probably implement, get signed, and give away a CryptoLib-based CSP (not for export) for which we will also make source available so people examine the source to their crypto (most CSPs will, presumably, not include source). Despite all this, I think it will be easy to get around the CSP signature requirements and use homebrew, unsigned crypto even with pre-compiled .exe files from other sources. I suspect it will be easy to write a program, for example, that takes an executable program and converts CryptoAPI calls to calls that look like just another DLL. And I'm sure someone will write a program to patch the NT/Windows kernel to ignore the signature check. Needless to say, it would be nice if someone outside the US were to write and distribute programs to do this. It would also be nice if someone would write a Unix/Linux version of the API/CSP mechanism. It might make it possible to export applications for those platforms as well. I haven't tried any of this out yet, but they say they will have beta versions of the API and CSP developers kits out in a few weeks. They say that the API kit will not be export-controlled but the CSP kit will be. They plan to announce all this at the RSA conference this week. -matt