On Win 2003 32 bit, I successfully export a PRIVATEKEYBLOB with a CryptExportKey call (dwFlags=0). Then I attempt to import the key blob on a Win Server 2008 64 bit with a 64 bit executable, the call to CryptImportKey fails with NTE_BAD_DATA.
In both cases the crypto provider is initialized with a call to
CryptAcquireContext(&hProv,
szContainer, NULL, PROV_RSA_AES,
CRYPT_MACHINE_KEYSET)
The passwords to export/import match. The public key is based on a CryptDeriveKey of an md5 hash of passwords that are identical in their plain text represetnation. I’m not sure whether the public keys end up being equal in the two systems.
Are the different types of systems (Win 2003 32 bit vs Win 2008 64 bit) the expected cause of failure, and is there a way of getting this to work?
As conjectured the public keys produced by ATL’s CCryptDerivedKey were not equal on the two systems. The default settings of CCryptDerivedKey must be different in the two versions of ATL library.
Since I had access to both the source and destination servers, I could reexported and imported the key in a consistent manner – specifying algorithm, key size and presence of salt.
It would be nice to know what the exact settings of CCryptDerivedKey::Initialize method were in earlier version of ATL library (Visual Studio 2005, I believe).