La conversion de la clé avec OpenSSL n'est pas très facile ; vous devrez coder vous-même toute l'analyse PGP, voir RFC 4880 . Une fois que vous avez les valeurs n et e sous forme de tableaux d'octets, vous pouvez les placer dans des bignums, puis dans une structure RSA, et appeler ensuite PEM_write[_bio]_RSA_PUBKEY . Personnellement, je préférerais le faire en Java à l'aide de BouncyCastle, qui prend directement en charge les clés PGP et les données dans le format bcpg et les clés OpenSSL (et quelques données) dans le fichier bcpkix bocal.
La conversion des données est probablement impossible. Tout d'abord, il est très peu probable qu'un "message" soit simplement crypté avec RSA - RSA n'est adapté qu'à des données de taille limitée, actuellement environ 200 octets, et ce n'est généralement pas suffisant pour les données souhaitées (autres que les "twits"). Dans la pratique, les systèmes et les applications utilisent presque toujours un cryptage "hybride" : les données sont cryptées à l'aide d'un algorithme "symétrique" (classique, à clé secrète) tel que l'AES avec une clé nonce, et la clé nonce est cryptée à l'aide de l'algorithme RSA "asymétrique" (à clé publique). Il existe plusieurs façons d'effectuer le cryptage RSA et des dizaines, voire des centaines de façons différentes (appelées "modes") d'effectuer le cryptage symétrique. Vous devez trouver exactement le type de cryptage effectué par l'"outil".
PGP, dans le cas (habituel) du destinataire de la clé publique, utilise ce qui était à l'origine le cryptage PKCS1 "block type 02", aujourd'hui renommé RSAES-PKCS1-v1_5, combiné à l'un des nombreux algorithmes symétriques (certains courants, d'autres non) dans une variante du mode CFB que personne d'autre n'utilise (très peu d'autres choses au cours de ce siècle utilisent le mode CFB). tous de la BFC). Le destinataire de PGP peut n'accepter qu'un sous-ensemble d'algorithmes symétriques, et si c'est le cas, cela est exprimé dans le bloc de clés PGP, que l'expéditeur est censé lire et respecter, mais le format de clé publique utilisé par OpenSSL, à savoir la structure SubjectPublicKeyInfo de X.509/PKIX ne peut pas représenter cette information. (Un certificat X.509/PKIX certificat qui est également pris en charge par OpenSSL et que la plupart des logiciels OpenSSL bien conçus utilisent, pourrait représenter ces informations, mais sous une forme très différente de celle de PGP).
De plus, la variante CFB de PGP n'est pas authentifiante. En 1990, on n'avait pas réalisé qu'il s'agissait d'une vulnérabilité, mais aujourd'hui, c'est le cas. nombreux les destinataires exigent ou du moins préfèrent utiliser l'option PGP pour s'authentifier, c'est-à-dire ce que d'autres appellent aujourd'hui un code d'authentification des messages, mais que PGP appelait un code de détection des modifications. Le schéma MDC de PGP n'est pas le même que le schéma MAC utilisé par d'autres.
En bref, à moins que l'"outil" n'ait été conçu pour effectuer le cryptage PGP, son résultat ne peut être "converti" en PGP qu'en le décryptant et en le recryptant. Et s'il a été conçu par une personne saine d'esprit pour faire du cryptage PGP, il accepterait déjà une clé publique PGP. Cependant, comme il n'existe aucun moyen pour l'outil de déterminer si une clé publique "SPKI" telle que décrite ci-dessus appartient réellement au destinataire, vous pouvez générer votre propre clé publique "SPKI". propre donne à l'outil votre publickey, recevoir les données cryptées à l'aide de votre et la décrypte, puis la recrypte dans un format compatible avec PGP en utilisant la clé réelle du destinataire et un algorithme (et une option MDC) correspondant à cette clé.
