Générateur gratuit de paires de clés RSA — ECDSA, Ed25519

Générez vos clés RSA en ligne : la clé privée ne quitte pas le navigateur. RSA 2048/4096, ECDSA, Ed25519, PEM PKCS#8 ou PKCS#1, JWK et empreinte SHA-256.

Sans pistage Fonctionne dans le navigateur Gratuit

Les paires de clés sont générées dans votre navigateur avec l'API Web Crypto, et aucune requête réseau n'est émise pendant la génération. Coupez la connexion et cette page fonctionne toujours.

Algorithme

Taille de clé

Structure PEM

PKCS#8 (BEGIN PRIVATE KEY) est la valeur par défaut moderne et ce qu'attend le JDK. PKCS#1 (BEGIN RSA PRIVATE KEY) est la forme traditionnelle d'OpenSSL, encore exigée par certaines passerelles. Basculer réencode la même clé.

Clé privée

Gardez-la secrète. Quiconque la détient peut se faire passer pour vous.

Clé publique

Empreinte de la clé publique — SHA-256 du DER SPKI

JWK (JSON Web Key)

JWK privée — à ne jamais publier

JWK publique

Générer le même type de paire de clés avec OpenSSL

Vérifié pour la conformité aux RFC 5958/5208 (PKCS#8), RFC 8017 (PKCS#1), RFC 8410 (Ed25519) et à l'encodage PEM de la RFC 7468, ainsi que pour le comportement de l'API Web Crypto sur RSA, ECDSA et Ed25519. — Équipe Sécurité Go Tools · 10 août 2026

Notre équipe vérifie la conversion PKCS#8 vers PKCS#1 octet par octet face à la sortie de référence du module crypto de Node, si bien qu'une clé exportée ici est identique à celle qu'OpenSSL produirait pour le même matériel cryptographique.

Qu'est-ce qu'un générateur de clés RSA ?

Un générateur de clés RSA produit une paire liée mathématiquement : une clé privée que vous gardez et une clé publique que vous distribuez. Tout ce qui est signé avec la moitié privée se vérifie avec la moitié publique, et seule la moitié publique peut être publiée sans risque. Cette asymétrie est tout l'intérêt du procédé : elle permet à un vérificateur de contrôler vos signatures sans acquérir la capacité de les falsifier, ce qu'un secret partagé ne pourra jamais offrir.

Ce générateur s'exécute dans votre navigateur via l'API Web Crypto : la clé privée est créée dans l'onglet et la page n'émet aucune requête réseau pendant la génération. Au-delà de RSA, il produit aussi des paires ECDSA et Ed25519, qui rendent le même service avec des clés bien plus courtes : une clé privée Ed25519 pèse 48 octets en PKCS#8, là où une clé RSA de 2048 bits dépasse 1,2 Ko.

Ce qui fait trébucher, ce n'est pas la mathématique mais l'emballage. La même clé peut s'écrire en PKCS#8, PKCS#1, SPKI ou JWK, et une bibliothèque qui rejette l'un acceptera souvent l'autre sans message plus clair qu'une erreur d'analyse. Le tableau plus bas associe chaque conteneur aux écosystèmes qui l'attendent.

// Verify a downloaded key pair matches, using OpenSSL:
openssl pkey -in rsa-2048-private.pem -pubout | diff - rsa-2048-public.pem
// No output means the public key really belongs to that private key.

Fonctionnalités clés

Généré dans votre navigateur

Les clés proviennent de l'API Web Crypto dans votre propre onglet, et la page n'émet aucune requête réseau pendant la génération. Coupez votre connexion et elle continue de fonctionner, ce qui montre que l'outil n'a besoin d'aucun serveur pour faire son travail.

RSA, ECDSA et Ed25519

RSA 2048, 3072 et 4096 ; ECDSA sur P-256, P-384 et P-521 ; et Ed25519, le tout depuis une seule page avec les mêmes options d'export.

Sortie PKCS#8 et PKCS#1

Basculez entre BEGIN PRIVATE KEY et la disposition traditionnelle BEGIN RSA PRIVATE KEY sans toucher à OpenSSL. Le sélecteur réencode la clé déjà affichée : c'est toujours la même clé.

Export JWK

Les deux moitiés sont disponibles en JSON Web Keys. La JWK publique est celle qui va dans un document JWKS ou chez un vérificateur JOSE ; la JWK privée n'appartient qu'à votre signataire et ne doit jamais être publiée.

Empreinte SHA-256

Chaque paire est accompagnée d'une empreinte de sa clé publique pour vérifier hors bande que les deux parties détiennent la même clé.

Commandes OpenSSL correspondantes

Les commandes équivalentes pour générer le même type de clé en local s'affichent sous la sortie, pour passer à la ligne de commande quand vous préférez.

Téléchargements aux noms parlants

Les fichiers sont enregistrés sous rsa-2048-private.pem et rsa-2048-public.pem, et non sous un nom générique qu'il faut renommer.

Sans compte, sans quota

Aucun serveur n'intervient : il n'y a donc rien à créer comme compte ni aucun quota à épuiser.

Exemples concrets

Paire Ed25519, affichée en entier

Algorithme : Ed25519

Une clé privée Ed25519 fait 48 octets en PKCS#8 et la clé publique 44 octets, donc chaque PEM tient sur une seule ligne de base64. Cette paire est une démonstration jetable — générez la vôtre plutôt que de recopier celle-ci.

Les en-têtes PKCS#8 et PKCS#1 diffèrent

Algorithme : RSA 2048, structure basculée

PKCS#8:  -----BEGIN PRIVATE KEY-----
PKCS#1:  -----BEGIN RSA PRIVATE KEY-----

Même clé, deux emballages. PKCS#8 ajoute un identifiant d'algorithme autour de la structure RSA, ce qui explique qu'il convienne à tous les algorithmes alors que PKCS#1 n'existe que pour RSA. Basculer le sélecteur réencode la clé déjà affichée, donc l'empreinte ne change pas.

Clé publique RSA 2048

Algorithme : RSA 2048

Le préfixe MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A est l'identifiant d'algorithme rsaEncryption : c'est à lui qu'on reconnaît une clé SPKI RSA au premier coup d'œil.

Clé publique au format JWK

Algorithme : Ed25519, panneau JWK

{
  "key_ops": [
    "verify"
  ],
  "ext": true,
  "alg": "Ed25519",
  "crv": "Ed25519",
  "x": "V5uB7UaPJrtncx3SXNtNzn1ZXjF1ApwvzBZ8nFzT5eU",
  "kty": "OKP"
}

C'est l'export tel quel, y compris les membres key_ops et ext que Web Crypto ajoute systématiquement. Une entrée JWKS n'en veut pas — supprimez les deux, et ajoutez plutôt kid et use pour que les vérificateurs puissent sélectionner la bonne clé pendant une rotation. Ed25519 relève du type de clé OKP ; les clés RSA apparaissent avec kty RSA et les membres n et e.

Empreinte SHA-256

Algorithme : Ed25519

SHA256(SPKI) = KAXVxapxpG4zLsTVMpPafovT+X1NLWc8fsOXqtrb59o=

Un condensat SHA-256 de la structure de clé publique, assez court pour être lu au téléphone. Attention, ce n'est pas la valeur qu'affiche ssh-keygen : OpenSSH hache son propre format de transport, si bien que les deux ne coïncident jamais pour une même clé.

Comment utiliser le générateur de clés RSA

1

Choisissez l'algorithme

RSA couvre le plus large éventail de systèmes hérités. ECDSA offre une force équivalente dans des clés bien plus courtes. Ed25519 est la valeur par défaut moderne pour toute nouvelle signature.
2

Choisissez la taille de clé

RSA 2048 répond aux recommandations actuelles ; 3072 et 4096 ajoutent de la marge pour les clés à longue durée de vie. ECDSA propose P-256, P-384 et P-521. Ed25519 n'a qu'une seule taille.
3

Sélectionnez la structure PEM

PKCS#8 émet BEGIN PRIVATE KEY et fonctionne presque partout, y compris sur le JDK. Ne passez à PKCS#1 que lorsqu'un composant exige spécifiquement BEGIN RSA PRIVATE KEY.
4

Copiez ou téléchargez les deux moitiés

La clé privée part dans votre gestionnaire de secrets. La clé publique va à celui qui vérifie vos signatures. N'envoyez jamais la moitié privée où que ce soit.
5

Vérifiez l'empreinte

Comparez l'empreinte SHA-256 sur un canal séparé pour confirmer que l'autre partie a bien installé la clé publique que vous avez générée.

Erreurs courantes de format de clé

Coller la clé publique là où va la clé privée

La signature exige la moitié privée. Une bibliothèque à qui l'on donne BEGIN PUBLIC KEY alors qu'elle attendait une clé privée renvoie en général une erreur d'analyse peu parlante au lieu de nommer le vrai problème.

✗ Incorrect

-----BEGIN PUBLIC KEY-----

✓ Correct

-----BEGIN PRIVATE KEY-----

Mauvaise structure PEM pour la bibliothèque

Quelques écosystèmes ne lisent que la disposition RSA traditionnelle — la sortie -traditional d'OpenSSL elle-même, certains SDK de passerelles de paiement, l'outillage Ruby et Perl ancien. La plupart des bibliothèques modernes, et le JDK en particulier, attendent PKCS#8. Basculez le sélecteur de structure PEM plutôt que de chercher une commande de conversion.

✗ Incorrect

-----BEGIN RSA PRIVATE KEY-----

✓ Correct

-----BEGIN PRIVATE KEY-----

Perdre le saut de ligne final

Un fichier PEM se termine par un saut de ligne après le dernier délimiteur. Une copie qui passe par un champ de formulaire supprimant les espaces produit un fichier que certains analyseurs rejettent purement et simplement — et comme le caractère manquant est invisible, le fichier paraît correct dans un éditeur.

✗ Incorrect

-----END PRIVATE KEY-----[EOF]

✓ Correct

-----END PRIVATE KEY-----↵[EOF]

Un caractère perdu en chemin

Ce qui casse un PEM, c'est un caractère perdu, inséré ou substitué, pas la largeur des lignes — la plupart des analyseurs acceptent n'importe quel repli. Une copie passée par un client de discussion ou un champ de formulaire peut silencieusement transformer un retour à la ligne en espace, et le base64 ne donne aucun indice sur le caractère fautif ; la clé refuse simplement de se charger. Utilisez le bouton de copie plutôt qu'une sélection à la main.

✗ Incorrect

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni eSccN1uleXFRBb1g2TN6bk

✓ Correct

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni
eSccN1uleXFRBb1g2TN6bk

Utiliser un secret HS256 alors que RS256 est configuré

HS256 prend un seul secret partagé ; RS256 prend une paire de clés. Donner une chaîne aléatoire à un signataire RS256 échoue dès l'analyse. Générez la paire ici, ou utilisez notre générateur de secret JWT si vous vouliez HS256.

✗ Incorrect

alg: RS256, key: 8f3a9c2e1b7d

✓ Correct

alg: RS256, key: -----BEGIN PRIVATE KEY-----

Coller un PEM dans authorized_keys

Une clé publique SSH est au format OpenSSH sur une ligne, ssh-ed25519 AAAA…, et non un bloc PEM : coller la clé publique de cette page dans authorized_keys ne fonctionnera pas. Pour une clé RSA, vous pouvez dériver la bonne ligne en local avec ssh-keygen -y ; pour un accès SSH en général, générer sur la machine cible reste préférable.

✗ Incorrect

-----BEGIN PUBLIC KEY-----

✓ Correct

ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub

Qui utilise cet outil

Signer des JWT en RS256 ou EdDSA: Les algorithmes JWT asymétriques exigent une paire de clés plutôt qu'un secret partagé. Vous signez avec la clé privée, vous publiez la clé publique, et les vérificateurs ne détiennent jamais de quoi fabriquer des jetons. Notre encodeur JWT accepte les clés produites ici.
Signer des webhooks et des releases: Publiez la clé publique une fois, signez chaque charge utile avec la clé privée, et vos consommateurs vérifient l'authenticité sans identifiant partagé susceptible de fuiter.
Développement local et tests: Une suite de tests qui exerce la vérification de signature a besoin d'une paire jetable. En générer une ici va plus vite que de retrouver l'invocation OpenSSL.
Comprendre à quoi ressemble une paire de clés: Basculer entre les algorithmes et les structures PEM côte à côte rend les différences concrètes, là où la lecture d'une spécification reste abstraite.
Préparer un point de terminaison JWKS: La JWK publique s'insère telle quelle dans le tableau keys d'un document de découverte OpenID Connect. Ajoutez un kid pour que les vérificateurs puissent la sélectionner pendant une rotation, et gardez la JWK privée hors de ce fichier.
Migrer de RSA vers autre chose: Générez le remplacement Ed25519 à côté de l'original RSA et comparez les tailles avant de vous engager dans le changement.
Corriger une incompatibilité de format: Quand une bibliothèque rejette une clé avec une erreur d'analyse, la réémettre dans l'autre structure PEM suffit généralement à tout résoudre.

Les formats PEM et le fonctionnement du générateur

Quel conteneur pour quel usage: Une clé, cinq emballages. Se tromper d'emballage est la première cause de rejet d'une clé, et le message d'erreur dépasse rarement le stade de l'échec d'analyse.
Conteneur En-tête PEM Contient Où vous le croisez
PKCS#8 BEGIN PRIVATE KEY Tout algorithme Web Crypto, le JDK, Go, .NET — la plupart des bibliothèques modernes
PKCS#1 BEGIN RSA PRIVATE KEY RSA uniquement Sortie traditionnelle d'OpenSSL, certaines passerelles de paiement, outillage Ruby et Perl ancien
SPKI / X.509 BEGIN PUBLIC KEY Tout algorithme, moitié publique La clé publique qu'attend presque toute bibliothèque
PKCS#1 publique BEGIN RSA PUBLIC KEY RSA uniquement, moitié publique Outillage RSA hérité
JWK aucun — c'est du JSON Tout algorithme Points de terminaison JWKS, découverte OIDC, bibliothèques JOSE
Pour convertir des fichiers que vous avez déjà, openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem fait la conversion dans un sens et openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem dans l'autre.
L'aléa vient du système d'exploitation: Web Crypto alimente la génération de clés depuis la source d'entropie de la plateforme — getrandom sous Linux, et le CSPRNG système sous Windows et macOS. C'est la même catégorie de source que celle où puise OpenSSL, pas un générateur pseudo-aléatoire JavaScript.
La génération ne fige pas la page: crypto.subtle.generateKey est asynchrone, et dans les principaux moteurs de navigateur la recherche des nombres premiers se fait hors du thread principal : l'interface reste réactive pendant qu'un module de 4096 bits est cherché. La page affiche quand même un indicateur d'activité, car la durée de cette recherche dépend de la chance du tirage.
PKCS#8 enveloppe PKCS#1: Un PrivateKeyInfo PKCS#8 se compose d'un numéro de version, d'un identifiant d'algorithme et d'un OCTET STRING. Pour une clé rsaEncryption non chiffrée, cet OCTET STRING contient une RSAPrivateKey PKCS#1 complète, et c'est exactement ainsi que cette page convertit de l'un à l'autre sans rien redériver.
Les clés publiques utilisent SubjectPublicKeyInfo: BEGIN PUBLIC KEY correspond à un SubjectPublicKeyInfo X.509 : un identifiant d'algorithme suivi d'un BIT STRING. Ce que contiennent ces bits dépend de l'algorithme — pour RSA, une RSAPublicKey PKCS#1, ce qui explique que BEGIN RSA PUBLIC KEY soit plus court ; pour ECDSA, le point de courbe non compressé, et pour Ed25519 la clé brute de 32 octets.
L'exposant public vaut 65537: Toutes les clés RSA produites ici utilisent e = 65537, écrit 0x010001. Il est assez grand pour écarter les attaques à petit exposant et n'a que deux bits à 1, si bien qu'une vérification coûte 16 élévations au carré et une seule multiplication.
Les empreintes portent sur le DER, pas sur le PEM: L'empreinte SHA-256 est calculée sur le SubjectPublicKeyInfo binaire. Empreindre le texte base64 à la place la ferait changer dès que le retour à la ligne change. L'équivalent en local est openssl pkey -in private.pem -pubout -outform DER | openssl dgst -sha256 -binary | openssl base64.

Conteneur	En-tête PEM	Contient	Où vous le croisez
PKCS#8	BEGIN PRIVATE KEY	Tout algorithme	Web Crypto, le JDK, Go, .NET — la plupart des bibliothèques modernes
PKCS#1	BEGIN RSA PRIVATE KEY	RSA uniquement	Sortie traditionnelle d'OpenSSL, certaines passerelles de paiement, outillage Ruby et Perl ancien
SPKI / X.509	BEGIN PUBLIC KEY	Tout algorithme, moitié publique	La clé publique qu'attend presque toute bibliothèque
PKCS#1 publique	BEGIN RSA PUBLIC KEY	RSA uniquement, moitié publique	Outillage RSA hérité
JWK	aucun — c'est du JSON	Tout algorithme	Points de terminaison JWKS, découverte OIDC, bibliothèques JOSE

Bonnes pratiques de gestion des clés

Générez les clés là où elles serviront: Une clé privée qui traverse un réseau a été exposée à chaque saut du trajet. Générer dans le navigateur garde la clé elle-même hors du réseau, même si le code de la page, lui, arrive par ce réseau ; générer sur la machine cible supprime jusqu'à l'étape de copie. Pour une clé qui protège des systèmes de production, préférez la machine cible.
Préférez Ed25519 sauf si RSA est imposé: Ed25519 offre une sécurité solide dans une clé de 32 octets, avec une signature rapide et aucun paramètre à mal choisir. Revenez à RSA quand un partenaire ou une vieille bibliothèque ne vous laisse pas le choix.
Considérez 2048 bits comme le plancher: Le NIST SP 800-131A interdit RSA en dessous de 2048 bits pour la génération de signatures depuis 2013, et aucune autorité de certification publique n'émettra contre une clé plus courte. Choisissez 3072 ou 4096 pour des clés censées rester en service de nombreuses années.
Ne committez jamais une clé privée: Placez les clés privées dans un gestionnaire de secrets ou une variable d'environnement chargée à l'exécution. Dès qu'une clé atteint un dépôt, la faire tourner est la seule réponse sûre.
Faites tourner selon un calendrier, pas seulement après un incident: Publiez les nouvelles clés publiques avec un identifiant de clé avant de retirer les anciennes, pour que les vérificateurs acceptent les deux pendant le chevauchement. Une rotation pratiquée en routine est une rotation qui tient sous pression.

Foire aux questions

Est-il sûr de générer une clé privée sur un site web ?

La clé est générée par l'API Web Crypto dans votre propre navigateur, et cette page n'émet aucune requête réseau pendant la génération — vous pouvez surveiller l'onglet Réseau, ou couper la connexion et constater que la génération fonctionne toujours. Soyez clair sur ce que cela démontre et sur ce que cela ne démontre pas : cela prouve que la page n'a besoin d'aucun serveur, mais ce n'est pas une garantie contre un script compromis, puisque le JavaScript est retéléchargé depuis notre serveur à chaque visite. Les risques qui subsistent relèvent du navigateur plutôt que du réseau — une extension malveillante peut lire la page et votre presse-papiers, et quiconque a accès à la machine peut lire le fichier téléchargé. Pour une clé qui protège des systèmes de production, générez-la sur la machine qui l'utilisera ; les commandes OpenSSL ci-dessous font exactement cela. Cette page est le bon outil pour le développement, les tests, l'apprentissage et partout où une clé générée dans un navigateur est acceptable.

Quelle est la différence entre PKCS#8 et PKCS#1 ?

Ce sont deux conteneurs pour la même clé RSA. PKCS#1, marqué BEGIN RSA PRIVATE KEY, contient directement les nombres RSA et n'existe que pour RSA. PKCS#8, marqué BEGIN PRIVATE KEY, enveloppe ces mêmes nombres dans un identifiant d'algorithme, ce qui permet à un seul format de porter aussi bien RSA qu'ECDSA ou Ed25519. La plupart des bibliothèques modernes attendent PKCS#8 — le JDK, notamment, ne lit que PKCS#8 sans bibliothèque supplémentaire — tandis qu'un certain nombre de passerelles de paiement et d'outils de l'époque OpenSSL exigent encore PKCS#1. Basculer le sélecteur sur cette page réencode la clé déjà affichée : rien n'est ajouté ni perdu et l'empreinte reste la même.

Comment convertir une clé PKCS#1 en PKCS#8, et inversement ?

Basculez le sélecteur de structure PEM sur cette page et la même clé est réémise dans l'autre conteneur. Pour un fichier que vous avez déjà, OpenSSL convertit en local : openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem transforme un fichier BEGIN RSA PRIVATE KEY en BEGIN PRIVATE KEY, et openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem fait l'inverse. Aucun des deux sens n'ajoute ni ne retire de matériel cryptographique ; seul l'emballage change, et c'est pourquoi les deux fichiers décrivent la même clé et produisent la même empreinte.

Comment obtenir la clé publique à partir d'une clé privée RSA ?

La clé publique se dérive de la clé privée, jamais l'inverse. Cette page affiche les deux moitiés en même temps, il n'y a donc rien à dériver. Pour une clé privée déjà sur votre disque, openssl pkey -in private.pem -pubout -out public.pem écrit le fichier BEGIN PUBLIC KEY correspondant. C'est aussi la façon de vérifier qu'une paire va bien ensemble : régénérez la moitié publique et comparez-la au fichier qu'on vous a remis.

Faut-il choisir RSA ou Ed25519 ?

Choisissez Ed25519 quand rien ne vous force la main. Il atteint une sécurité comparable à RSA 3072 avec une clé de 32 octets, signe plus vite et n'a aucun paramètre à mal configurer. Choisissez RSA quand un partenaire, une autorité de certification ou une vieille bibliothèque l'impose, ce qui reste courant dans les systèmes d'entreprise et de paiement. ECDSA se situe entre les deux et bénéficie d'un large support en TLS.

RSA 2048 bits est-il encore assez robuste ?

Oui, pour la plupart des usages actuels. Le NIST évalue RSA 2048 bits à un niveau de sécurité de 112 bits et le maintient jusqu'en 2030 dans le SP 800-57 ; 3072 bits atteint 128 bits de sécurité et c'est ce que le NIST vise au-delà. Donc : 2048 pour tout ce que vous ferez tourner d'ici quelques années, 3072 ou 4096 pour une clé que vous voyez encore en service dans les années 2030 ou quand une autorité de certification l'exige. Le coût de la clé plus longue, c'est une signature plus lente et des signatures plus volumineuses, pas une sécurité moindre.

Puis-je utiliser ces clés pour signer des JWT ?

Oui. Les clés RSA fonctionnent avec RS256, RS384 et RS512 ainsi qu'avec les variantes PSS ; ECDSA P-256 va de pair avec ES256 ; et Ed25519 correspond à l'algorithme EdDSA. Signez avec la clé privée et publiez la clé publique pour que les vérificateurs puissent contrôler les signatures sans pouvoir en créer. Une réserve si vous utilisez le panneau JWK plutôt que le PEM : Web Crypto estampille une JWK RSA avec alg RS256, et les bibliothèques strictes refusent de la charger pour PS256 ou RS512 — supprimez le membre alg, ou utilisez le PEM. Notre encodeur JWT accepte ces clés, et le décodeur montre ce que contient le jeton obtenu.

Cet outil peut-il générer une clé SSH ?

Pas directement. Le fichier de clé privée propre à OpenSSH est un conteneur différent, que cette page n'écrit pas. Une clé RSA d'ici reste utilisable : ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub dérive la ligne authorized_keys depuis le fichier que vous avez téléchargé. Les clés Ed25519 d'ici, en revanche, ne le sont pas, car OpenSSH rejette leur forme PKCS#8. Pour un accès SSH, la meilleure réponse reste ssh-keygen -t ed25519 sur la machine qui a besoin de la clé, ce qui évite tout déplacement de clé privée. Pour la signature de JWT, la signature de releases en CI et la vérification de webhooks, la clé PKCS#8 que produit cette page est exactement ce qu'attendent ces outils.

Puis-je protéger la clé privée par une phrase secrète ?

Pas ici. Le PKCS#8 chiffré nécessite une étape de dérivation de clé que l'API Web Crypto n'expose pas : l'implémenter reviendrait à bricoler de la cryptographie en JavaScript. Ajoutez plutôt la phrase secrète en local : openssl pkcs8 -topk8 -in private.pem -out encrypted.pem lit le fichier que vous avez téléchargé et vous la demande.

À quoi sert l'empreinte ?

C'est un condensat SHA-256 de la structure de clé publique, assez court pour être comparé de vive voix ou dans un message. Quand vous envoyez une clé publique à quelqu'un, comparer les empreintes sur un canal séparé confirme que ce qui est arrivé correspond à ce que vous avez envoyé. Elle identifie uniquement la clé publique et ne révèle rien de la moitié privée. Notez que ce n'est pas le nombre qu'affiche ssh-keygen -l : OpenSSH hache son propre format de transport plutôt que la structure SPKI, si bien que les deux ne correspondent jamais pour une même clé.

Outils connexes

Voir tous les outils →

Outil de déchiffrement AES — compatible OpenSSL et CryptoJS

Outils de sécurité

Déchiffrez de l'AES en ligne — GCM/CBC/CTR, phrase secrète ou clé brute, détection automatique du format OpenSSL et CryptoJS « U2FsdGVkX1 ». 100 % dans le navigateur, les clés ne quittent jamais la page.

Outil de chiffrement AES — GCM, CBC et CTR

Outils de sécurité

Chiffrement AES en ligne gratuit — AES-128/192/256, GCM/CBC/CTR, phrase secrète (PBKDF2) ou clé brute. 100 % dans votre navigateur ; rien n'est envoyé.

Générateur et vérificateur de hachage Bcrypt

Outils de sécurité

Générez et vérifiez des hachages bcrypt en ligne — coût ajustable, préfixes $2b$/$2a$/$2y$. 100 % dans votre navigateur ; mot de passe jamais envoyé.

Générateur HMAC & vérificateur de signature

Outils de sécurité

Générateur et vérificateur HMAC en ligne gratuit. Calculez HMAC-SHA256/SHA1/SHA384/SHA512 avec des clés en texte, hex ou Base64 et une sortie Hex/Base64/Base64URL. 100 % dans votre navigateur — les clés ne quittent jamais la page.

Décodeur JWT

Outils de sécurité

Décodez des jetons JWT en ligne avec notre décodeur JWT gratuit. Inspectez en-tête, charge utile, signature, expiration et revendications. 100 % navigateur — votre jeton ne quitte jamais votre appareil. Sans inscription ni suivi.

Encodeur & Générateur JWT

Outils de sécurité

Générateur & encodeur JWT gratuit en ligne. Construisez l'en-tête et la charge utile, signez avec HS256, RS256 ou ES256 instantanément. 100 % navigateur — votre secret et votre clé ne quittent jamais votre appareil.

Générateur gratuit de paires de clés RSA — ECDSA, Ed25519

Générer le même type de paire de clés avec OpenSSL

Qu'est-ce qu'un générateur de clés RSA ?

Fonctionnalités clés

Généré dans votre navigateur

RSA, ECDSA et Ed25519

Sortie PKCS#8 et PKCS#1

Export JWK

Empreinte SHA-256

Commandes OpenSSL correspondantes

Téléchargements aux noms parlants

Sans compte, sans quota

Exemples concrets

Paire Ed25519, affichée en entier

Les en-têtes PKCS#8 et PKCS#1 diffèrent

Clé publique RSA 2048

Clé publique au format JWK

Empreinte SHA-256

Comment utiliser le générateur de clés RSA

Choisissez l'algorithme

Choisissez la taille de clé

Sélectionnez la structure PEM

Copiez ou téléchargez les deux moitiés

Vérifiez l'empreinte

Erreurs courantes de format de clé

Coller la clé publique là où va la clé privée

Mauvaise structure PEM pour la bibliothèque

Perdre le saut de ligne final

Un caractère perdu en chemin

Utiliser un secret HS256 alors que RS256 est configuré

Coller un PEM dans authorized_keys

Qui utilise cet outil

Les formats PEM et le fonctionnement du générateur

Bonnes pratiques de gestion des clés

Foire aux questions

Outils connexes

Outil de déchiffrement AES — compatible OpenSSL et CryptoJS

Outil de chiffrement AES — GCM, CBC et CTR

Générateur et vérificateur de hachage Bcrypt

Générateur HMAC & vérificateur de signature

Décodeur JWT

Encodeur & Générateur JWT