According to Matt Blaze: [[ Prelude about MS Cryptography API deleted ]]
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.
Did MS mention how the crypto DLL's would be "protected" from surreptitious tampering? What I'm wondering is if it will be possible to "drop in" a new (signed) crypto.dll (that just happens to forward cleartext to the DLL author, or perhaps uses intentionally deficient (or just fixed) keys) when installing, for example, the latest game craze distributed on the Internet? It would seem to be fairly sketchy (and dangerous) to allow drop-in crypto engines if those can be replaced with *ANY* other crypto engine at any time (note for the paranoid: Imagine "NSA the Game" for Windows(TM) with the new "Send the Feds a copy" encryption DLL--that last part in fine print of coures :) I am hoping that they do have some for of protection against this that hasn't been mentioned yet, but this kind of jumps out at me when I think of drop-in DLLs (anyone ever see how well the WINSOCK.DLL scheme works? God Forbid that an encryption scheme be subject to the same problems!) --Sean #include <std_disclaimer.h>