Comment utiliser correctement OAEPEncoding Bouncy Castle pour RSA (Lightweight API)

Question

J'ai joué avec l'implémentation de Bouncy Castle de RSA (Lightweight API) et j'ai compris les bases. En regardant leur spec pour l'implémentation du fournisseur JCE, j'ai remarqué que différents schémas de remplissage peuvent être utilisés avec RSA. D'après ce que je comprends, par défaut, le remplissage de null est utilisé. J'ai donc commencé à explorer le rembourrage OAEP, en particulier OAEPWithSHA512AndMGF1Padding. La recherche avec Google n'a pas été très utile, j'ai donc commencé à fouiller dans le code source de la Colombie-Britannique et j'ai trouvé la classe org.bouncycastle.jce.provider.JCERSACipher. Mais en regardant initFromSpec rapidement m'a donné un mal de tête ... Plus précisément, je ne comprends pas ce que les deux derniers paramètres qui peuvent être transmis au constructeur OAEPEncoding sont. Selon l'API de BC, le constructeur OAEPEncoding qui accepte quatre paramètres accepte Digest mgf1Hash et byte[] encodingParams comme les deux derniers arguments. Cela m'a bloqué parce que je ne sais pas comment obtenir une instance de l'algorithme de génération de masque et je ne comprends pas le but derrière le tableau d'octets appelé encodingParams. Quelles devraient être les valeurs de arg3 et arg4 dans le code ci-dessous?

RSABlindedEngine rsa = new RSABlindedEngine(); 
SHA512Diges sha512 = new SHA512Digest(); 
Digest arg3 = ???; 
byte[] arg4 = ???; 
AsymmetricBlockCipher cipher = new OAEPEncoding(rsa, sha512, arg3, arg4); 

Answer 1

OAEP est spécifié par PKCS#1, section 7.1.

OAEP requiert les paramètres suivants:

• une fonction de hachage;
• une "fonction de génération de masque" qui peut être considérée comme une fonction de hachage avec une longueur de sortie illimitée;
• un "label" (une séquence arbitraire d'octets).

Il n'existe qu'une seule fonction de génération de masque définie, appelée MGF1, et cette fonction est construite sur une fonction de hachage. Donc, votre arg3 est la fonction de hachage que MGF1 utilisera. Il peut s'agir de la même fonction de hachage que la première (je ne suis pas sûr que ce soit la même instance Digest dans l'API Bouncy Castle, je parle mathématiquement ici). Cela peut aussi être une autre fonction de hachage.

L'étiquette peut être utilisée comme une sorte de distinction entre les instances (par exemple, vous pouvez crypter des données avec un "but" explicite codé dans l'étiquette). C'est pratique dans certaines preuves mathématiques, mais actuellement, PKCS # 1 recommande d'utiliser une chaîne vide et d'en finir avec elle. Pour les raisons décrites dans PKCS # 1, une étiquette vide est aussi bonne que n'importe laquelle.

Le processus de déchiffrement doit connaître ces paramètres pour fonctionner. Il est habituel de les encoder dans la structure qui accompagne le message crypté et dit "ceci est crypté avec RSA/OAEP"; Voilà comment cela se passe dans CMS.

En cas de doute, utilisez la même fonction de hachage comme premier paramètre et pour MGF1, et utilisez une étiquette vide.