1

Sur Windows 2003 32 bits, j'exporte avec succès un PRIVATEKEYBLOB avec un appel CryptExportKey (dwFlags = 0). Ensuite, je tente d'importer la clé blob sur un Win Server 2008 64 bits avec un exécutable 64 bits, l'appel à CryptImportKey échoue avec NTE_BAD_DATA.CryptoAPI - exportation/importation de clés entre différentes versions de Windows

Dans les deux cas, le fournisseur de Crypto est initialisé par un appel à

CryptAcquireContext (& hProv, szContainer, NULL, PROV_RSA_AES, CRYPT_MACHINE_KEYSET)

Les mots de passe à l'exportation/match d'importation . La clé publique est basée sur un CryptDeriveKey d'un hachage md5 de mots de passe identiques dans leur représentation en texte brut. Je ne suis pas sûr que les clés publiques finissent par être égales dans les deux systèmes. Les différents types de systèmes (Win 2003 32 bits vs Win 2008 64 bits) sont-ils la cause probable de l'échec, et existe-t-il un moyen de faire fonctionner ce système?

Répondre

0

Comme supposé les clés publiques produites par CCryptDerivedKey d'ATL n'étaient pas égales sur les deux systèmes. Les paramètres par défaut de CCryptDerivedKey doivent être différents dans les deux versions de la bibliothèque ATL. Comme j'avais accès aux serveurs source et de destination, je pouvais réexporter et importer la clé de manière cohérente - en spécifiant l'algorithme, la taille de la clé et la présence de sel.

Il serait bon de savoir quels étaient les paramètres exacts de la méthode CCryptDerivedKey :: Initialize dans la version antérieure de la bibliothèque ATL (Visual Studio 2005, je crois).

Questions connexes