2010-11-17 20 views
2

J'essaie d'importer une paire de clés publique/privée RSA générée avec l'API Win32 Crypto dans une application .NET. Le code qui crée et exporte la paire de clés ressemble à ceci:Comment puis-je importer une clé privée RSA dans un RSACryptoServiceProvider?

// Abbreviated for clarity. 
CryptAcquireContext(..., MS_ENHANCED_PROV, ...); 

// Generate public/private key pair 

CryptCreateHash(..., CALG_SHA1, ...); 
CryptHashData(hash, password, ...); 
CryptDeriveKey(..., CALG_3DES, hash, CRYPT_EXPORTABLE, ...); 
CyrptExportKey(..., derivedKey, PRIVATEKEYBLOB, ...); 

Fondamentalement, ce code exporte la paire clé publique/privée en tant que blob crypté. Il utilise l'algorithme 3DES pour le cryptage avec une clé dérivée d'un hachage SHA-1. Maintenant, lorsque j'essaie d'importer cette clé dans .NET, j'ai des problèmes. J'ai essayé d'approches:

(1) créer un autre objet RSACyrptoServiceProvider et appelez ImportCspBlob(). Cela déclenche une exception avec le message "données incorrectes". Ce n'est pas surprenant puisque l'objet fournisseur n'a aucun moyen de savoir comment le blob a été chiffré. Pour autant que je sache, il n'y a aucun moyen de dire quel algorithme et clé utiliser pour cela.

(2) Je décrypte manuellement le blob moi-même, en utilisant la classe PasswordDeriveBytes, puis je passe le blob déchiffré à ImportCsbBlob(). Encore une fois, je reçois une exception. Cette fois, le message est "mauvaise version du fournisseur". J'ai essayé de fournir manuellement le nom du fournisseur ("Microsoft Enhanced Cryptographic Provider v1.0") lors de la création de l'objet fournisseur, mais cela ne fait aucune différence.

Il est essentiel que cela fonctionne. Des idées?

SOLUTION

Après avoir généré les paires clés publiques non crypté/privé dans les deux C++ et .NET, je découvre que le fournisseur Microsoft Enhanced Cryptographic ne chiffre pas réellement les 8 premiers octets de la paire de clés. (Cela doit être l'information de version qui lançait l'encapsuleur .NET pour une boucle.) Après avoir modifié mon code de déchiffrement .NET pour laisser les 8 premiers octets tout seul, tout fonctionne bien.

Cette solution est très bonne car elle dépend de la mise en œuvre detials interne du fournisseur cryptographique. Malheureusement, je ne pense pas que Microsoft ait négligé de fournir une version de ImportCspBlob qui vous permet de spécifier un algorithme et une clé pour le décryptage.

Répondre

2

Dans l'approche 2), vérifiez que la clé décryptée est la même qu'avant le cryptage.

Je ne pense pas « une clé dérivée d'un hachage SHA-1 » correspondra à un de PasswordDeriveBytes

+0

Je suis sûr que la dérivation clé fonctionne, mais je vais voir si je peux comparer les deux textes en clair –

+0

Cela m'a mis sur la bonne voie, merci. –