Un paquet d'information sur les clefs contient toutes les informations au sujet d'une clef privée ou publique. Il y a quatre variantes de ce type de paquet, et deux versions majeures. Par conséquent, cette section est complexe.
Un paquet sur les clefs publiques commence par une série de paquets qui forme une clef OpenPGP (parfois appelée un certificat OpenPGP).
Un paquet sur les sous clefs publiques (Tag 14) possède exactement le même format qu'un paquet sur les clefs publiques, mais signale une sous-clef. Une ou plusieurs sous-clefs peuvent être associées avec une clef de niveau supérieur. Par convention, la clef de niveau supérieur fournit les services de signatures, et les sous-clefs fournissent les services de cryptage.
Note: dans PGP 2.6.x, le tag 14 a été conçu pour indiquer un paquet de commentaire. Ce tag a été sélectionné pour réutilisation car aucune version précédente de PGP n'a jamais émis de paquets de commentaire mais au contraire elles les ignoraient carrément. Les paquets sur les sous-clefs publiques sont ignorés par PGP 2.6.x et ne le font pas planter, fournissant un peu de compatibilité descendante.
Un paquet sur les clefs secrètes contient toutes les informations trouvées dans un paquet sur les clefs publiques, y compris les informations sur les clefs publiques, mais il comprend aussi les informations sur les clefs secrètes, qui se trouvent après tous les champs de clefs publiques. secrète après tous les champs de clef publique.
Un paquet sur les sous-clefs secrètes (tag 7) est l'équivalent pour les sous-clefs du paquet et a exactement le même format.
Il y a deux versions de paquets d'information sur les clefs. Les paquets de Version 3 ont été générés à l'origine par PGP 2.6. Les paquets de Version 2 sont de formats identiques aux paquets de Version 3, mais sont générés par PGP 2.5 ou antérieur. Les paquets V2 sont a rejeter et ne DOIVENT ABSOLUMENT PAS être générés. PGP 5.0 à introduit les paquets de Version 4, avec de nouveaux champs et de nouvelles sémantiques. PGP 2.6.x n'acceptera pas les paquets d'information sur les clefs de version supérieure à 3.
Les implémentations de OpenPGP DOIVENT créer des clefs avec le format de la version 4. Une implémentation PEUT générer une clef V3 pour assurer l'interropérabilité avec les anciens logiciels; notez, cependant, que les clefs V4 corrigent quelques défaillance de sécurité des clefs V3. Ces défaillances sont décrites ci-dessous. Une implémentation ne DOIT EN AUCUN CAS créer une clef V3 avec un algorithme à clef publique autre que RSA.
Un paquet Version 3 sur une clef publique ou sur une sous-clef publique contient :
Un numéro de version (3) sur un octet.
Un nombre de quatre octets indiquant la date de création de la clef.
Un nombre de deux octets indiquant la durée de validité en jours de la clef. Si ce nombre est zéro, la clef n'expire pas.
Un nombre d'un octet indiquant l'algorithme de clef publique de cette clef.
Une série d'entiers multi-précision comprenant les informations suivantes sur les clefs :
un entier multi-précision (MPI ndt:Multi Precision Integer) de modulo publique RSA n;
un MPI de cryptage publique RSA exposant e.
Les clefs V3 DOIVENT seulement être utilisées pour des questions de compatibilité antérieure car elle comporte trois points faibles. Premièrement, il est relativement facile de construire une clef V3 qui possède le même identifiant de clef qu'une autre clef car l'identifiant de clef est simplement constitué des 64 bits de poids faible du modulo publique. Deuxièmement, car l'empreinte d'une clef V3 hache les informations sur la clef, mais pas sa longueur, ce qui accroit les possibilités de conflits d'empreintes. Troisièmement, il y a quelques petites lacunes dans l'algorithme de hachage MD5 qui font que les développeurs préfèrent les autres algorithmes. Vous trouverez ci-dessous pour une discussion plus complète des identifiants de clefs et des empreintes.
Le format de la version 4 est similaire à celui de la version 3 excepté en ce qui concerne l'absence de la période de validité. Elle a été déplacée dans le paquet de signature. De plus, les empreintes des clefs de version 4 sont calculées différemment de celles de la version 3, comme décrit dans la section "Formats de clefs amélioré".
Un paquet de version 4 contient:
Un numéro de version (4) d'un octet.
Un nombre de quatre octets indiquant la date de création de la clef.
Un nombre d'un octet indiquant l'algorithme de clef publique de la clef.
Une série d'entiers multiprécision comprenant les informations de clef. La portion spécifique à l'algorithme est :
Les champs spécifiques à l'algorithme pour des clefs publiques RSA :
entier multi-précision (MPI) de public RSA modulo n;
MPI de cryptage publique RSA d'exposant e.
Les champs spécifiques à l'algorithme pour les clefs publiques DSA :
un MPI de nombre premier DSA p;
un MPI d'ordre de groupe DSA q (q est un diviseur du nombre premier p-1);
un MPI de générateur de groupe DSA g;
un MPI de valeur de clef publique DSA y (= g**x où x est secret).
Les champs spécifiques à l'algorithme pour des clefs publiques Elgamal :
un MPI de nombre premier Elgamal p;
un MPI de groupe générateur Elgamal g;
un MPI Elgamal de valeur de clef publique y (= g**x où x est secret).
Ces paquets sur une clef secrète et sur une sous-clef secrète contiennent toutes les données et la paquets de clef publique de sous-clef publique, auxquelles sont ajoutés des données de clef secrète supplémentaire spécifiques à l'algorithme, sous forme cryptée. [XXXXXXXXXXXXXXXXX]
Le paquet contient:
un paquet sur la clef publique et la sous-clef publique, comme décrit ci dessus
Un octet indiquant les conventions d'usage des string-to-key. 0 indique que les données de clef secrète ne sont pas cryptées. 255 indique qu'un identifiieur string-to-key est donnée. Toutes les autres valeurs, sont des identifieurs d'algorithme de cryptage à clef symétrique.
[Optionnel] Si l'octet d'usage string-to-key était 255, un algorithme de cryptage symétrique d'un octet.
[Optionnel] Si l'octet d'usage string-to-key était 255, un identifieur string-to-key. La longueur de l'identifieur est induite par son type, comme décrit ci dessus.
[Optionnel] Si la donnée secrète est cryptée, un Vecteur Initial de huit octets (IV).
Des entiers multi-précision cryptés comprenant les données de la clef secrète. Ces champs spécifiques à l'algorithme sont décrits si dessous.
Un checksum de deux octets du texte brut de la partie spécifique à l'algorithme (la somme de tous les octets, mod 65536).
Des champs spécifiques à l'algorithme pour les clefs secrètes RSA:
un entier multiprécision (MPI) d'exposant secret RSA d.
MPI de valeur secrète de nombre premier RSA p.
MPI de valeur secrète de nombre premier RSA q (p < q).
MPI de u, l'inverse multiplicatif de p, module q.
Des champs spécifiques à l'algorithme pour les clefs secrètes DSA:
Un MPI d'exposant secret DSA x.
Un MPI d'exposant secret Elgamal x.
Les valeurs MPI secrètes peuvent être cryptées en utilisant une phrase mot de passe. Si un identifieur string-to-key est donné, celui-ci décrit l'algorithme pour convertir la phrase secrète en une clef, sinon un simple hachage MD5 de la phrase secrète est utilisé. Les implémentations DOIVENT utiliser un identifieur string-to-key; l'utilisation d'un hachage simple sert a garder la compatiblité antérieure. Le chiffrage pour crypter les MPI est spécifié dans le paquet de clef secrète.
Le cryptage/décryptage des données secrètes est faite en mode CFB en utilisant la clef créée à partir de la phrase secrète et le Vecteur Initial venant du paquet. Un mode différent est utilisé avec les clefs V3 (qui ne sont que de type RSA) par rapport aux autres formats de clefs. Avec les clefs V3, le préfixe de comptage de bit MPI (i.e., les deux premiers octets) n'est pas crypté. Seules les données non préfixés MPI sont cryptées. De plus, l'état CFB est resynchronisé au début de chaque nouvelle valeur MPI, de manière à ce que la limite de bloc CFB soit aligné avec le début des données MPI.
Avec les clefs V4, une méthode plus simple est utilisée. Toutes les valeurs secrètes MPI sont cryptées en mode CFB, y compris le préfixe de comptage de bit MPI.
Le checksum 16-bit qui suit la partie spécifique à l'algorithme est la somme algébrique, mod 65536, du texte brut de tous les octets spécifiques d'algorithme (incluant le préfixe et les données MPI). Avec les clefs V3, le checksum est stocké en clair. Avec les clefs V4, le checksum est crypté comme les données spécifiques à l'algorithme. Cette valeur est utilisée pour vérifier que la phrase mot de passe est correcte.
| Précédent | Sommaire | Suivant |
| Paquets de signature à une passe (Tag 4) | Niveau supérieur | Paquet des données compressées (Tag 8) |