Inspecteur de clés OpenPGP et analyseur de paquets

Collez une clé, une signature ou un message OpenPGP en armure — ou chargez un fichier binaire .gpg — et consultez l’empreinte, l’identifiant de clé, les identités utilisateur, les sous-clés, les paquets de signature et l’arbre brut des paquets. Tout se fait dans votre navigateur ; rien n’est envoyé.
Analyseur uniquement. Cet outil décode et affiche des données OpenPGP — il ne vérifie jamais cryptographiquement les signatures, ne déchiffre jamais et ne demande jamais de phrase de passe. Pour réellement vérifier ou déchiffrer, utilisez GnuPG (gpg --verify, gpg -d) avec votre propre trousseau. Et comme pour tout outil : les clés privées réelles ont leur place dans votre trousseau, pas dans un onglet de navigateur.
Entrée OpenPGP (texte d’armure ASCII, ou vidange hexadécimale des octets de paquets bruts, ou fichier binaire ci-dessous)
Accepte tous les types d’armure : PUBLIC KEY BLOCK, PRIVATE KEY BLOCK, MESSAGE, SIGNATURE, ARMORED FILE.
export binaire de trousseau / .sig / .gpg — lu localement, jamais envoyé
Ce que contrôle cet outil — et ce qu’il ne fait volontairement pas
Il décode l’armure (étiquette, en-têtes, charge utile base64, la somme de contrôle CRC-24 de transport), analyse chaque paquet aux formats d’en-tête ancien et nouveau, lit les paquets de clé v4/v5/v6 (algorithme, tailles des MPI, date de création), calcule les empreintes v4 (SHA-1) et v6 (SHA-256), dérive les identifiants de clé, et liste les identités utilisateur, les sous-clés et les sous-paquets de signature. Il ne vérifie pas les signatures (cela exige toute la mécanique de hachage et de vérification de la RFC 9580 §5.2.4 ainsi qu’un trousseau de confiance), ne déchiffre pas, et ne récupère pas de clés auprès des serveurs de clés. Recoupez toute sortie avec GnuPG : gpg --show-keys file.asc affiche l’empreinte et les identités utilisateur, gpg --list-packets file.asc vide la structure des paquets.
Clés d’exemple sur cette page — les quatre boutons Exemple collent une vraie clé OpenPGP v4 RSA-2048 générée uniquement pour cette page (jamais utilisée ailleurs). La clé privée d’exemple est volontairement stockée non chiffrée (usage S2K 0), afin que l’analyseur puisse montrer la disposition des MPI secrets ; une vraie clé privée exportée afficherait plutôt son chiffrement et sa dérivation S2K.
Autotest
Relance l’analyseur sur la clé d’exemple intégrée, une signature détachée et un message signé : étiquettes d’armure, contrôle CRC-24 et corruption volontaire, suites de tags de paquets, empreinte v4 et identifiant de clé comparés à des valeurs calculées indépendamment, identités utilisateur, empreintes de sous-clés, détection de clé secrète, ainsi que des tests négatifs (une entrée inutilisable et des paquets tronqués doivent être rejetés). Rien n’est envoyé nulle part.
OpenPGP expliqué depuis le début
En une phrase : OpenPGP est un standard ouvert (RFC 4880, mis à jour par la RFC 9580 en 2024) pour le chiffrement de bout en bout et les signatures numériques, surtout connu pour sécuriser le courrier électronique — et tout circule sous forme de petits paquets binaires étiquetés, généralement enveloppés dans une couche d’« armure » compatible texte.
Qu’est-ce qu’OpenPGP ?

PGP (« Pretty Good Privacy ») a été publié par Phil Zimmermann en 1991 comme programme que chacun pouvait utiliser pour chiffrer et signer des messages. Pour sortir du problème d’un seul éditeur, le format des messages a été normalisé sous le nom d’OpenPGP (RFC 2440 en 1998, RFC 4880 en 2007, RFC 9580 en 2024). Aujourd’hui, GnuPG est l’implémentation la plus répandue, et le même format de paquets apparaît aussi dans les commits git signés, la signature de paquets logiciels, les serveurs de clés et l’enregistrement DNS OPENPGPKEY.

Le modèle est de bout en bout : vous et votre correspondant générez chacun une paire de clés personnelle ; tout ce qui est chiffré pour vous ne peut être déchiffré que par votre clé privée, qui ne quitte jamais votre machine. Au lieu d’une autorité de certification centrale (comme pour TLS), la confiance dans les clés d’autrui repose sur le fait de signer mutuellement les clés — le « web of trust ». Utiliser ce réseau ou simplement comparer les empreintes hors bande (un appel téléphonique, une carte de visite) vous appartient ; le format lui-même n’impose ni l’un ni l’autre.

Qu’est-ce qu’une clé OpenPGP ?

Une « clé » OpenPGP est en réalité un petit ensemble de paquets : un paquet de clé primaire (votre ancre d’identité, généralement autorisée à signer), un ou plusieurs paquets d’identité utilisateur (« Alice <alice@example.com> »), des auto-signatures liant ces identités à la clé primaire, et facultativement des sous-clés avec leurs propres signatures de liaison — généralement une sous-clé de chiffrement distincte, pour que la précieuse clé primaire puisse rester hors ligne. Le bloc complet en armure que vous collez dans cette page constitue cet ensemble.

L’empreinte est le hachage du paquet de clé primaire — SHA-1 (20 octets) pour les clés v4, SHA-256 (32 octets) pour les clés v6 — calculé sur la seule partie publique. L’identifiant de clé n’est que les 8 derniers octets d’une empreinte v4 (les 8 premiers pour la v5). Les empreintes servent à être comparées hors bande, pour vérifier que personne n’a remplacé la clé en chemin ; les identifiants de clé sont un raccourci pour les serveurs de clés et ne sont pas à l’abri des collisions face à un attaquant déterminé.

Identifiant d’algorithmeNomUsage typique dans une clé
1RSAClassique polyvalent ; 2048 à 4096 bits, signature et/ou chiffrement
19ECDSACourbes NIST (P-256 et autres), signature
18ECDHAccord de clés Curve25519/P-256, sous-clés de chiffrement
22EdDSASignature Ed25519 (la valeur moderne par défaut dans GnuPG 2.4+)
25X25519Sous-clés de chiffrement associées à des clés primaires Ed25519 (clés v6)

Un bloc de clé privée porte les nombres secrets après la partie publique : un octet d’usage S2K indiquant comment ils sont protégés (0 = non protégé, 254/255 = clé dérivée d’une phrase de passe avec un chiffrement), puis les MPI secrets et une somme de contrôle. Cette page affiche ce mode de protection mais ne demande jamais de phrase de passe et ne tente jamais de déchiffrer le matériel secret.

Qu’est-ce qu’un paquet OpenPGP ?

Sous l’armure, chaque objet OpenPGP est une suite de paquets. Chacun commence par un octet de tag : l’ancien format y place un type de paquet sur 4 bits et un type de longueur, le nouveau format (CTB, bit 6 à 1) utilise un type sur 6 bits et des octets de longueur capables de décrire des données par morceaux partiels. Tags courants : 6 = clé publique, 5 = clé secrète, 14 = sous-clé, 13 = identité utilisateur, 2 = signature, 4 = signature à passe unique, 11 = données littérales, 8 = données compressées, 18 = données chiffrées protégées par MDC. Cette page affiche le tag, le format d’en-tête, la longueur et une vidange hexadécimale pour chaque paquet trouvé, et signale par une position d’octet tout en-tête de paquet mal formé.

Les paquets de signature transportent leurs métadonnées dans des zones de sous-paquets hachés et non hachés. Seule la zone hachée est couverte par la signature elle-même ; la zone non hachée (utilisée historiquement pour l’identifiant de clé de l’émetteur) peut être réécrite librement par n’importe qui en transit, les lecteurs doivent donc la traiter comme une indication, jamais comme un fait. C’est l’auto-signature d’une identité utilisateur qui lie réellement le nom à la clé ; un paquet de clé seul, collé isolément, ne prouve rien quant à son propriétaire.

L’armure ASCII est l’enveloppe textuelle : -----BEGIN PGP PUBLIC KEY BLOCK-----, des en-têtes facultatifs comme Version: ou Comment:, le base64 du flux de paquets, et une ligne finale =xxxx contenant un CRC de 24 bits. Ce CRC ne détecte que les corruptions de transport — modifiez un seul caractère base64 et cette page le signale — mais ce n’est pas une signature et il ne prouve rien quant à l’auteur.

Erreurs courantes
  • Faire confiance à une clé sans comparer les empreintes. Quiconque peut générer une clé portant n’importe quel nom. La comparaison des empreintes sur un canal déjà fiable (en personne, par téléphone) constitue toute l’étape d’authentification.
  • Confondre le CRC de l’armure avec une signature. Un badge « CRC OK » signifie seulement que le base64 a bien voyagé, rien de plus. La vérification est une opération cryptographique que cette page n’effectue volontairement pas.
  • Utiliser les identifiants de clé comme identité. Les identifiants de clé de 64 bits peuvent être falsifiés par un attaquant disposant d’une puissance de calcul modeste (une « collision d’identifiant de clé ») — citez toujours les empreintes complètes.
  • Coller de vraies clés privées dans des pages web. Même une page locale sans envoi comme celle-ci est une habitude à ne pas prendre. Les exemples ici sont des clés jetables générées pour la démonstration.
  • Supposer que « PGP MESSAGE » signifie chiffré. L’étiquette d’armure ne dit rien du contenu — le message d’exemple de cette page est signé mais en clair, et c’est le tag de paquet 18 ou 11 qui distingue réellement les données chiffrées des données littérales.
  • Importer des clés v3. Les clés de version 3 (conception antérieure à 1996, identifiants de clé 16 bits faibles) sont obsolètes depuis 2014 ; cet inspecteur les refuse volontairement.
FAQ

Cet outil vérifie-t-il les signatures ? Non. Il analyse et affiche. La vérification d’une signature exige toute la construction de l’en-queue de hachage de la RFC 9580, la clé publique du signataire et la décision de faire confiance à cette clé — le travail de GnuPG ou d’une bibliothèque OpenPGP.

En quoi est-ce différent d’openpgp.js ? openpgp.js est une implémentation complète (chiffrer, déchiffrer, signer, vérifier) que vous intégrez à votre application ; cette page est un inspecteur sans dépendance pour lire et auditer les structures OpenPGP dans le navigateur.

Peut-il lire mon export GnuPG ? Oui — clés v4, v5 et v6, signatures détachées et messages. Les clés de version 3 sont refusées avec une note (obsolètes depuis 2014).

Pourquoi un mode d’entrée hexadécimal ? Les données OpenPGP brutes sont binaires ; si vous disposez d’une vidange hexadécimale d’un trousseau ou d’un fichier .gpg, collez l’hexadécimal et l’analyseur le traite exactement comme les octets décodés.

Quelque chose est-il envoyé ? Non. L’analyse, le calcul des empreintes et la génération du rapport se font tous dans cet onglet ; la page s’exécute entièrement dans votre navigateur.