Format des listings "---with-colons" ==================================== sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch : ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0::: 1. Champ: Type d'enregistrement pub = clef publique sub = sous-clef (clef secondaire) sec = clef secrète ssb = sous-clef secrète (clef secondaire) uid = id d'utilisateur (seul le champ 10 est utilisé) sig = signature fpr = fingerprint: (le champ 10 est le fingerprint) pkd = données publiques de la clef (champ au format spécial, voir ci-dessous) 2. Champ: Une lettre décrivant la confiance calculée. Ce n'est qu'une seule lettre, mais elle fera peut-être l'objet d'une information supplémentaire pour les versions futures, comme décrit ici (ceci ne sera pas utilisé pour les clefs privées) o = Inconnu (cette clef est nouvelle au système) i = La clef est invalide (eg. il manque sa propre signature) d = La clef a été désactivée r = La clef a été révoquée e = La clef a expiré q = Non-défini (pas de valeur attribuée) n = Ne jamais faire confiance à cette clef m = Cette clef dispose d'une confiance marginale f = Cette clef dispose d'une confiance totale u = Cette clef dispose d'une confiance ultime. Cette valeur n'est utilisée que pour les clefs où la clef secrète est également disponibles. 3. Champ: taille de la clef en bits. 4. Champ: Algorithme utilisé: 1 = RSA 16 = ElGamal (chiffrement uniquement) 17 = DSA (parfois appellé DH, signature seulement) 20 = ElGamal (signe et chiffre) (pour d'autres is, consultez include/cipher.h) 5. Champ: ID de clef (KeyID) 6. Champ: Date de création (en UTC) 7. Champ: Date d'expiration de la clef, vide si aucune. 8. Champ: ID local : numéro d'enregistrement du répertoire dans la trustdb. Cette valeur n'est valide que tant que la trustdb n'est pas effacée. Vous pouvez utiliser "#" comme id d'utilisateur lorsque vous spécifiez la clef. Ceci est requis puisque les id de clef ne sont pas toujours uniques - un programme peut donc utiliser ce numéro pour accéder aux clefs ultérieurement. 9. Champ: Confiance propre (clef publiques primaires uniquement) C'est une simple lettre, mais une information supplémentaire pourrait se voir ajoutée dans les versions futures. 10. Champ: ID utilisateur. La valeur est placée entre guillemets comme une chaîne en C, par exemple : "\x3a". 11. Champ: Classe de signature. C'est un nombre hexadécimal à deux chiffres suivi par la lettre "x" si la signature peut être exportée ou la lettre "l" si la signature est uniquement locale. 12. Champ: Capacités de la clef : e = chiffrement s = signature c = certification Une clef peut disposer de toute combinaison de ces caractéristiques. La clef primaire dispose, en plus de ces lettres, une version en majuscule des lettres pour marquer les capacités "d'utilisation" de la totalité de la clef. Toutes les dates sont affichées dans le format : yyyy-mm-dd Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet d'additions dans les futures versions et les parsers doivent y être préparés. Lorsque le parser traitera ces données, il devra s'arrêter au premier caractère non-numérique afin que des informations supplémentaires soient ajoutées à l'avenir. Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci : pkd:0:1024:B665B1435F4C2 .... FF26ABB: ! ! !-- la valeur ! !------ indicateur du nombre de bits de la valeur !--------- index (eg. DSA va de 0 à 3 : p,q,g,y) Format de la sortie "--status-fd" ================================= Chaque ligne dispose d'un préfixe : "[GNUPG:] " Suivie par un mot clef indiquant le type de la ligne de statut, et quelques arguments selon le type (probablement aucun) ; une application devrait toujours assumer que des arguments supplémentaires seront présents dans les versions futures. GOODSIG La signature keyid est valide. Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou ERRSIG seront produits et ils pourront être utilisés comme marqueurs pour les nouvelles signatures. BADSIG La signature keyid n'a pas été vérifiée correctement. ERRSIG \ Il n'a pas été possible de vérifier la signature. Ceci peut provenir d'une clef publique manquante, ou bien à cause d'un algorithme non- supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique une clef publique manquante. Les autres champs donnent plus d'information sur la signature. sig_class est une valeur hexadécimale de 2 octets. VALIDSIG La signature keyid est valide. C'est ici la même chose que GOODSIG mais avec le fingerprint comme argument. Les lignes de statut seront émises pour une bonne signature. sig-timestamp est la date de création de la signature en secondes depuis Epoch. SIG_ID N'est émis que pour les signatures de classe 0 ou 1 qui ont été vérifiées comme valides. Le chaîne est un identifiant d'utilisateur et peut être utilisée dans les applications pour détecter les attaques par rejeu de messages signés. Notez que seuls les algorithmes DLP offrent des identifiants uniques ; les autres peuvent produire des id dupliqués lorsqu'ils furent créés à la même seconde. ENC_TO Le message est chiffré avec ce keyid. keytype est une valeur numérique de l'algorithme à clef publique, keylength est la taille de la clef ou 0 si elle n'est pas connue (ce qui est toujours le cas). NODATA Aucune donnée n'a été trouvée. Les codes suivants sont utilisés : 1 - Pas de données sous ARMOR. 2 - Un paquet attendu n'a pas été trouvé. 3 - Paquet invalide trouvé ; ceci peut indiquer un message non-OpenPGP. Vous devez vous attendre à une extension de ces lignes de statu à l'avenir. UNEXPECTED Des données innatendues ont été rencontrées 0 - pas de détail supplémentaire TRUST_UNDEFINED TRUST_NEVER TRUST_MARGINAL TRUST_FULLY TRUST_ULTIMATE Pour les signatures valides, l'une de ces lignes de statut sera produite pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments pour l'instant. SIGEXPIRED La clef de signature a expiré. Pas d'arguments pour l'instant. KEYREVOKED L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant. BADARMOR L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant. RSA_OR_IDEA Les algorithmes IDEA ont été utilisés sur les données. Un programme pourra basculer sur un autre programme de traitement si GnuPG échoue. Ce message de statut sera affiché pour le RSA aussi, mais ceci a été abandonné puisque le brevêt sur le RSA a expiré. Toutefois, nous ne pouvons modifier le nom du message. SHM_INFO SHM_GET SHM_GET_BOOL SHM_GET_HIDDEN GET_BOOL GET_LINE GET_HIDDEN GOT_IT NEED_PASSPHRASE Sera affiché à chaque fois qu'une phrase passe sera requise. keytype est la valeur numérique de l'algorithme à clef publique ou bien 0 si cela n'est pas applicable. keylength est la taille de la clef ou 0 si la taille n'est pas connue (ceci est actuellement toujours le cas). NEED_PASSPHRASE_SYM Affiché à chaque fois qu'une phrase passe pour un chiffrement symétrique sera requise. MISSING_PASSPHRASE Aucune phrase passe n'a été fournie. Une application qui rencontre ce message devrait stopper immédiatement le parsing car le prochain message sera probablement BAD_PASSPHRASE. Toutefois, si l'application n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs, ceci pourrait avoir un autre sens et stopper le parsing pourrait être incorrect, et il faudra ignorer le BAD_PASSPHRASE. BAD_PASSPHRASE La phrase passe fournie est soit invalide, soit n'a pas été fournie. Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE. GOOD_PASSPHRASE La phrase passe fournie est valide et le matériel de clefs secrète est utilisable. DECRYPTION_FAILED La déchiffrement symétrique a échoué. Il s'agit généralement d'une mauvaise phrase passe ne correspondant pas au message chiffré. DECRYPTION_OKAY Succès du déchiffrement. Ceci signifie que soit la clef secrète adaptée a été utilisée avec succès, soit que la phrase passe valide pour un chiffrement symétrique aura conduit au déchiffrement. Le programme pourait toutefois renvoyer un message d'erreur s'il n'a pas été possible de vérifier la signature. NO_PUBKEY NO_SECKEY La clef n'est pas utilisable. IMPORTED Le keyid et la signature ont été importés. IMPORTED_RES Statistiques finales sur le processus d'importation (cette ligne est longue!) FILE_START Début de traitement du fichier . indique l'opération réalisée : 1 - vérifier FILE_DONE Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START. BEGIN_DECRYPTION END_DECRYPTION Marque le début et la fin du processus de déchiffrement. Ces messages seront également produits lors de l'utilisation du mode --list-only. BEGIN_ENCRYPTION END_ENCRYPTION Marque le début et la fin du processus de chiffrement. DELETE_PROBLEM reason_code L'effacement d'une clef a échoué. Un code indique la raison de l'erreur : 1 - La clef spécifiée n'existe pas 2 - La clef privée doit être détruite avant ! PROGRESS what char cur total Utilisé par les fonctions primegen et de clef publique pour indiquer la progression de l'opération. "char" est le caractère affiché sans --status-fd avec les retours à la ligne marqués par "X". "cur" indique la quantitité de traitement terminée et "total" indique la valeur finale à atteindre. Un total de 0 indique que le total n'est pas connu. 100/100 peut être utilisé pour détecter la fin de l'opération. SIG_CREATED Une signature a été créée à l'aide de ces paramètres. type: 'D' = détachée 'C' = en texte clair 'S' = standard (seul le premier caractère doit être vérifié) class: 2 chiffres hexadécimaux avec la classe de signature KEY_CREATED Une clef a été créée type: 'B' = primaire et sous-clef 'P' = primaire 'S' = sous-clef SESSION_KEY : La clef de session utilisée pour déchiffrer le message. Ce message sera seulement affiché si l'option --show-session est utilisée. Le format est utilisable pour un passage direct à la fonction --override-session-key. NOTATION_NAME NOTATION_DATA Le nom et la chaîne sont "escaped" à l'aide de %XX et les données peuvent être découpées sur plusieurs lignes notation_data. USERID_HINT Donne un indice sur l'ID utilisateur pour un keyID donné. POLICY_URL La chaîne est "escaped" en %XX BEGIN_STREAM END_STREAM Produit par pipemode. Génération de clef ================== La génération de clef marque sa progression à l'aide de différents caractères, dont voici la signification : "." : les 10 derniers tests Miller-Rabin ont échoué. "+" : réussite du test Miller-Rabin. "!" : Rechargement du pool avec des nombres premiers frais. "^" : Vérification d'une nouvelle valeur pour le générateur. "<" : La taille d'un facteur a été réduite. ">" : La taille d'un facteur a été augmentée. Le nombre premier pour l'ElGamal est généré de la manière suivante : 1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille de la clef). 2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit au moins de la taille de q et on calcule le nombre de facteurs premiers requis. 3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée à l'étape 2. 4. On obtient une nouvelle permutation du pool et nous continuons avec l'étape 3 une fois toutes les permutations testées. 5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1 6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer q s'il ne semble pas possible de produire un premier de la taille voulue) 7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par le test de Miller-Rabin. 8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7. 9. On trouve un générateur pour ce premier. Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260). Génération de clef innatendue ============================= Cette fonction est actuellement expérimentale et permet la production de clefs innatendues avec un contrôle depuis un fichier de paramètres. Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne PAS vous plaindre si nous décidons d'apporter des modifications importantes à cette commande. Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en combinaison avec --batch et fournir les paramètres soit depuis stdin, soit depuis un fichier dont le nom est fourni en ligne de commande. Ce fichier devra utiliser le format suivant : o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères. o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII. o Les lignes vides seront ignorées. o Les espaces en début et fin de ligne seront ignorés. o Un signe "-" en tant que premier caractère "non white space" marque une ligne de commentaire. o Les commandes sont marquées par un signe "%" en début de ligne, suivi par la commande et ses arguments sont séparés par des espaces. o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les arguments sont séparés par des espaces. o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent être placés à votre discrétion. o La génération de clef aura lieu soit à la fin du fichier de paramètres, soit lorsque le premier "Key-Type" est rencontré au sein du fichier, dans un ensenble de contrôle "%commit". o Les ensembles de contrôle sont : %echo Affiche %dry-run Ne réalise pas la production de clef (pratique pour vérifier la syntaxe). %commit Réalise la production de clef. Un commit implicite est produit à chaque rencontre de "Key-Type". %pubring %secring Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring indiqué en ligne de commande, mais vers le fichier . Ce contrôle doit être utilisé avant que le commit ne soit rencontré. Toute double mention sera ignorée et le dernier nom de fichier rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce qu'un nouveau fichier soit spécifié (au points de commit) sinon toutes les clefs seront placées dans le même fichier. Si un nouveau nom de fichier est indiqué, le fichier sera créé (et tout ancien fichier sera alors écrasé). Les deux indications doivent être fournies au contrôle. o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui doit être le premier paramètre rencontré. Les paramètres ne sont destinés qu'au bloc keybloc généré et les paramètres des productions précédentes de clefs ne seront pas pris en compte. Certaines vérifications syntaxiques seront mises en place et peuvent être ou non actives. Les paramètres actuellement définis sont : Key-Type: | Débute un nouveau bloc de paramètres indiquant le type de la clef primaire à produire. L'algorithme doit être capable de produire des signatures. Ce paramètre est indispensable ! Key-Length: Indique la taille de la clef, en bits. La valeur par défaut est 1024. Subkey-Type: | Permet de produire une clef secondaire. Actuellement, seule une sous-clef peut être gérée. Subkey-Length: Taille de la sous-clef en bits. La valeur par défaut est 1024. Passphrase: Si vous souhaitez spécifier une phrase passe pour la clef secrète vous pouvez utiliser cette commande. Par défaut, aucune phrase passe ne sera associée aux clefs privées. Name-Real: Name-Comment: Name-Email: Voici les trois composantes d'une clef. Vous devez ici n'utiliser que de l'UTF-8. Si vous ne fournissez aucune de ces indications, aucun ID d'utilisateur ne sera créé. Expire-Date: |([d|w|m|y]) Spécifie la date d'expiration de la clef (et de sa sous-clef) La date doit être entrée sous la forme d'une date au format ISO (année-mois-jour) ou bien sous forme d'un nombre de jours, de semaines, de mois ou d'années. Si vous n'utilisez pas de lettre pour indiquer la durée, des "jours" sont assumés par défaut. Voici un exemple : $ cat >foo < ssb 1024g/8F70E2C0 2000-03-09 Composition de la TrustDB ========================= La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier octet décrit le type d'enregistrement. Toutes les valeurs numériques sont conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1 et c'est le seul enregistrement de ce type. Record type 0: -------------- Cet enregistrement n'est pas utilisé. Il peut être utilisé à votre discrétion. Record type 1: -------------- Indique la version de la TrustDB. Cet enregistrement doit toujours être le premier enregistrement de la base de données et c'est le seul enregistrement de type 1. 1 octet valeur : 1 3 octets 'gpg' valeur "magic" 1 octet Version de la TrustDB (2) 1 octet marginales requises 1 octet complètes requises 1 octet max_cert_depth Ces trois éléments sont utilisés pour vérifier si la valeur de validité mise en cache dans l'enregistrement du répertoire peut être utilisée : 1 u32 locked flags 1 u32 datation de la création de la trustdb 1 u32 datation de la dernière modification Cette datation pourrait affecter la validité des clefs dans la base de données. Cette valeur sera comparée à celle de la datation de validité des enregistrements dir : 1 u32 datation de la dernière validation Cette valeur sera utilisée pour stocker le passage du temps, lorsque cette TrustDB sera comparée au trousseau de clefs publiques : 1 u32 numéro de l'enregistrement du keyhashtable 1 u32 premier enregistrement libre 1 u32 numéro de l'enregistrement répertoire shadow de la table de hachage Cette table ne devrait pas être combinée avec la table de clefs car le keyid n'est pas dans chaque cas un élément du fingerprint. 4 bytes réservés pour l'enregistrement d'extension de version Record type 2: (enregistrement répertoire) -------------- Regroupe les informations sur un certificat de clef publique. Ces valeur sont statiques et ne sont jamais modifiées sans une interaction avec l'utilisateur : 1 octet valeur : 2 1 octet réservé 1 u32 LID . (numéro d'enregistrement de cet enregistrement) 1 u32 Liste de key-records (le premier est la clef primaire) 1 u32 Liste de uid-records 1 u32 cache record 1 octet ownertrust 1 octet dirflag 1 octet validité maximale de tous les id utilisateurs 1 u32 datation de la dernière vérification de validité 1 u32 Vérification requise lorsque cette datation sera atteinte (0 = pas de vérification requise) Record type 3: (enregistrement de clef) -------------- Regroupe les informations sur une clef publique primaire. (ces informations sont principalement utilisées pour réaliser les lookup dans l'enregistrement trust) 1 octet valeur : 3 1 octet réservé 1 u32 LID 1 u32 next - prochain enregistrement 7 octets réservés 1 octet keyflags 1 octet algorithme de la clef publique 1 octet taille du fingerprint (en octets) 20 octets fingerprint de la clef publique (Cette valeur est utilisée pour identifier toute clef) Record type 4: (enregistrement uid) -------------- Regroupe les informations sur un id utilisateur (un "uid"). Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire. 1 octet valeur : 4 1 octet réservé 1 u32 LID pointe vers l'enregistrement directory 1 u32 next le userid suivant 1 u32 pointeur vers l'enregistrement preference 1 u32 siglist liste de signatures valides 1 octet uidflags 1 octet validité de la clef calculée pour cet userid 20 bytes ripemd160 hachage du nom de l'utilisateur Record type 5: (enregistrement pref) -------------- Regroupe les informations formant les préférences. 1 octet valeur : 5 1 octet réservé 1 u32 LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!) (égal à 0 pour un enregistrement de préférences standard) 1 u32 suivant 30 byte données de préférences Record type 6 (sigrec) ------------- Cet enregistrement est utilisé pour traquer les signatures de clefs. Les auto-signatures ne sont pas conservées. Si une clef publique ne se trouve pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme, lequel contient une liste des enregistrements qui seraient intéressés par cette clef (et l'enregistrement signature en fait partie). 1 octet valeur : 6 1 octet réservé 1 u32 LID pointe en retour vers l'enregistrment dir 1 u32 next prochain sigrec de cet uid ou bien 0 pour indiquer que ce sigrec est le dernier. 6 times 1 u32 Local_id des dir signatures ou de l'enregistrement dir fantôme 1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un véritable enregistrement directory) 1 = valide est vrai (mais pourrait être révoqué) Record type 8: (enregistrement répertoire (dir) fantôme) -------------- Cet enregistrement est utilisé pour réserver un LID pour une clef publique. Nous avons besoin de cet enregistrement pour créer les enregistrements sigs des autres clefs, même si nous ne disposons pas d'une signature de la clef publique. Cet enregistrement (le numéro d'enregistrement pour être plus précis) sera réutilisé dans l'enregistrement dir lorsque nous importerons la véritable clef publique. 1 octet valeur : 8 1 octet réservé 1 u32 LID (Ceci est simplement le numéro d'enregistrement de ce record.) 2 u32 keyid 1 octet algorithme de la clef publique 3 octets réservé 1 u32 hintlist hintlist contient la liste des enregistrements qui ont des références qui pointent vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le code du programme saura prendre soin de tout cela. 18 octets réservés Record Type 10 (table de hachage) -------------- Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons implémenter un accès rapide en utilisant des méthodes de hachages simples, afin d'éviter une surcharge de gdbm. La propriété des fingerprint est qu'ils permettent un usage direct en tant que valeurs hachées (ils peuvent être considérés comme des nombres aléatoires cryptographiquement forts). Nous utilisons une architecture à multiples niveaux dynamique, qui combine les tables de hachage, les listes d'enregistrements et les listes chaînées. Cet enregistrement est une table de hachages de 256 entrées ; une propriété spéciale est que tous les enregistrements sont stockés consécutivement pour produire une grande table. La valeur hachée est simplement le 1er, 2nd.. octet du fingerprint (selon le niveau d'indirection). Lorsque nous les utilisons pour hacher les enregistrements de répertoires shadow, une différente table est utilisée, et elle se trouve indexée par le keyid. 1 octet valeur : 10 1 octet réservé n u32 recnum; n dépend de la taille de l'enregistrement : n = (reclen-2)/4 ce qui donne 9 pour la taille actuelle d'enregistrement de 40 octets. Le nombre total de ces enregistrements constituant la table est : m = (256+n-1) / n ce qui donne 29 pour une taille d'enregistrement de 40. Pour rechercher une clef, nous utilisons le premier octet du fingerprint pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement adressé : o Si cet enregistrement est une autre table de hachage, nous pouvons utiliser le second octet pour indexer cette table de hachage et continuer. o Si cet enregistrement est une liste de hachages, nous pouvons parcourir toutes les entrées jusqu'à trouver la bonne. o Si cet enregistrement est un enregistrement de clef, nous comparons le fingerprint avec celui recherché et nous déterminons s'il s'agit de la clef recherchée. Record type 11 (liste hachée) -------------- Consultez la table hachée pour une explication. Ceci sera également utilisé à d'autres fins. 1 octet valeur : 11 1 octet réservé 1 u32 next enregistrement de liste hachée suivant n times n = (reclen-5)/5 1 u32 recnum Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7. Record type 254 (enregistrement libre) --------------- Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés. 1 octet valeur 254 1 octet réservé (0) 1 u32 next_free En-têtes de paquets =================== GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens en-têtes de paquets : Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées dans la table suivante : 00 - 1-octet champ packet-length 01 - 2-octets champ packet-length 10 - 4-octets champ packet-length 11 - pas de taille de paquet fournie, taille inconnue Comme indiqué dans cette table, selon la taille du packet-length les octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont un "champ packet-length". Ce champ est une valeur numérique à part entière. La valeur du champ packet-length est définie par la valeur de la totalité du champ numérique. La valeur 11 est actuellement utilisée dans un cas : les données compressées. C''est à dire qu'un bloc de données compressées ressemble à : où A3 est le binaire "10 1000 11" et produit ici un paquet de taille non-définie. L'interprétation correcte en est : "jusqu'à la fin de la structure englobante" bien qu'en fait la structure englobante soit généralement le fichier. + Ceci sera modifié dans une future version, où la signification de la + valeur 11 (voir ci-dessous) aura aussi sa place. + + Une valeur de 11 pour d'autres paquets active un codage spécial + de la taille, où la taille du paquet suivant ne pourra pas être + déterminée avant l'écriture du paquet, en particulier ceci sera + utilisé si de grande quantités de données sont à traiter dans + un mode filtre. + + Ceci fonctionne de la manière suivante : après le CTB (qui est un + champ de longueur de 11) un champ marqueur sera utilisé, il indiquera + alors la taille du bloc de données suivant. C'est un simple champ + de deux octets (MSB en premier) contenant la quantité de données qui + suivent le champ, sans inclure le champ de taille toutefois. Après + ce bloc de données un autre champ de taille suivra, qui donnera la taille + du bloc de données suivant. Une valeur de 0 indique une fin de paquet. + La taille maximale d'un bloc de données est limitée à 65534, ce qui + réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de + taille devront être insérés dans le flux de données avant que les + données ne soient envoyées en sortie. + + Ce champ de deux octets est largement suffisant, car l'application + doit placer en tampon cette quantité de données pour précéder le + marqueur de taille avant de produire une sortie. Les blocs de données + d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra + également être utilisé pour les flux de données compressées, mais + nous devrons alors utiliser une autre version de paquet afin de dire à + l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet. Extensions GNU à l'algorithme S2K ================================= Le S2K mode 101 est utilisé pour identifier ces extensions. Après l'algorithme de hachage les trois octets "GNU" sont utilisés pour indiquer clairement qu'il s'agit d'extensions GNU et les octets qui suivent donnent le mode de protection GNU utilisé : 1000. Les modes définis sont : 1001 - ne pas conserver du tout de partie secrète Usage des fichiers gdbm pour les trousseaux de clefs ==================================================== La clef utilisé pour stocker le keyblock est son propre fingerprint, les autres enregistrements sont utilisés pour les clefs secondaires. Les fingerprint font toujours 20 octets où 16 bits de fingerprint sont suivis par 0. Le premier octet de chaque clef indique une information sur le type de clef : 1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0) les données sont le keyblock 2 = la clef est un keyid complet de 8 octets les données sont une liste de 20 octets fingerprints 3 = la clef est un keyid court de 4 octets les données sont une liste de 20 octets fingerprints 4 = la clef est une adresse email les données sont une liste de 20 octets fingerprints Les données sont pre-appended (précédées) par un octet de type : 1 = keyblock 2 = liste de 20 octets fingerprints "paddés" 3 = liste de liste de fingerprints ("but how to we key them?") Pipemode ======== Ce mode est utilisé pour réaliser des opérations multiples avec un unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier un grand nombre de signatures. Actuellement nous n'avons qu'un support des signatures détachées. Ce mode est une astuce qui permet d'éviter de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain Sockets pour lui faire passer les données. Il n'existe aucun moyen pratique de portabilité de ce concept sous Windows, alors nous utilisons des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous n'avons aucun moyen de signaler des EOF multiples dans un pipe nous devons laisser le contrôle s'insérer dans le flux de données lui-même. Nous réalisons alors une distinction entre les données du flux et un état de contrôle. A son lancement, le système se trouve dans un état de données mais n'acceptera aucune donnée. Il attend en fait une transition vers un mode de contrôle qui s'obtient en envoyant un simple caractère '@'. Une fois dans le mode de contrôle, des commandes sont attendues et ces commandes sont à un octet après lequel le système revient au mode de données (mais cela n'implique pas qu'il acceptera des données immédiatement). La commande de contrôle la plus simple est '@' qui permet d'insérer ce caractère dans le flux de données. Voici le format que nous utilisons pour les signatures détachées : "@<" - Début d'un nouveau flux "@B" - La signature détachée suit. Ceci émet le paquet de contrôle (1,'B') "@t" - Le texte signé suit. Ceci émet le paquet de contrôle (2, 'B') "@." - Fin de l'opération. Le paquet de contrôle final force la vérification de la signature. "@>" - Fin du flux. Autres notes ============ Dans la version* 3 de version de paquet nous calculons les keyid de cette manière : RSA : les 64 bits de poids faible de n ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99) et nous calculons une valeur hachée rmd160 à partir de ce paquet. Il est utilisé comme fingerprint avec les 64 bits de poids faible qui produisent le keyid. * Les certificats de révocation ne comportent qu'un paquet de signature ; "import" sait comment traiter ces paquets. L'idée derrière ce principe est de conserver une petite taille de paquet. Format des messages Keyserver ============================= Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP. Le format des requêtes est : ==== command-tag "Content-length:" digits CRLF ======= Où le command-tag est : NOOP GET PUT DELETE Le format de réponse utilisé est : ====== "GNUPG/1.0" status-code status-text "Content-length:" digits CRLF ============ suivi par octets de données. Les codes de statut utilisés sont : o 1xx: Information: requête reçue, traitement en cours. o 2xx: Succès - L'action a été reçue, comprise et acceptée. o 4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe ou demande irréalisable. o 5xx: Erreur serveur - Le serveur n'a pu traiter une demande qui semble valide. Documentation sur HKP (le protocol de serveurs de clefs http) ============================================================= Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET pour /pks/lookup. Les paramètres standard encodés URL de la requête sont toujours ceux-ci : (toujours key=valeur) - op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme pgp -kxa) - search=. Nous avons ici une liste de mots qui doivent apparaître dans la clef. Ces mots sont séparés par des espaces, points, @, etc. Les délimiteurs ne feront pas partie de la recherche et l'ordre des mots n'a aucune importance (mais consultez l'option suivante). - exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit rechercher que les correspondances exactes. Dans ce cas, les délimiteurs et l'ordre des mots sera considéré. - fingerprint=on. Renvoie également les fingerprint, lorsque utilisé avec 'index' ou 'vindex' Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add. Vous utilisez ceci pour envoyer des clefs au serveur. Le mieux pour produire une requête reste : /pks/lookup/?op= Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd. Toutefois, nous pensons que les traitements du serveur de clef doivent faire l'objet d'une refonte.