Format des listings "---with-colons"
====================================
sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
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
"#<local-id>" 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 <long keyid> <username>
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 <long keyid> <username>
La signature keyid n'a pas été vérifiée correctement.
ERRSIG <long keyid> <pubkey_algo> <hash_algo> \
<sig_class> <timestamp> <rc>
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 <fingerprint in hex> <sig_creation_date> <sig-timestamp>
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 <radix64_string> <sig_creation_date> <sig-timestamp>
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 <long keyid> <keytype> <keylength>
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 <what>
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 <what>
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 <long main keyid> <long keyid> <keytype> <keylength>
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 <cipher_algo> <s2k_mode> <s2k_hash>
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 <long keyid>
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 <long keyid>
NO_SECKEY <long keyid>
La clef n'est pas utilisable.
IMPORTED <long keyid> <username>
Le keyid et la signature ont été importés.
IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
Statistiques finales sur le processus d'importation (cette ligne est longue!)
FILE_START <what> <filename>
Début de traitement du fichier <filename>. <what> 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 <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
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 <type>
Une clef a été créée
type: 'B' = primaire et sous-clef
'P' = primaire
'S' = sous-clef
SESSION_KEY <algo>:<hexdigits>
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 <name>
NOTATION_DATA <string>
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 <long main keyid> <string>
Donne un indice sur l'ID utilisateur pour un keyID donné.
POLICY_URL <string>
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 <texte>
Affiche <texte>
%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 <filename>
%secring <filename>
Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring
indiqué en ligne de commande, mais vers le fichier <filename>. 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: <algo-number>|<algo-string>
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: <length-in-bits>
Indique la taille de la clef, en bits. La valeur par défaut est
1024.
Subkey-Type: <algo-number>|<algo-string>
Permet de produire une clef secondaire. Actuellement, seule une
sous-clef peut être gérée.
Subkey-Length: <length-in-bits>
Taille de la sous-clef en bits. La valeur par défaut est
1024.
Passphrase: <string>
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: <string>
Name-Comment: <string>
Name-Email: <string>
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: <iso-date>|(<number>[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 <<EOF
%echo Génération d'une clef standard
Key-Type: DSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: Joe le testeur
Name-Comment: ma phrase passe est stupide
Name-Email: joe@foo.bar
Expire-Date: 0
Passphrase: abc
%pubring foo.pub
%secring foo.sec
# Un commit est requis ici, pour pouvoir afficher un "done" :-)
%commit
%echo done
EOF
$ gpg --batch --gen-key -a foo
[...]
$ gpg --no-default-keyring --secret-keyring foo.sec \
--keyring foo.pub --list-secret-keys
/home/wk/work/gnupg-stable/scratch/foo.sec
------------------------------------------
sec 1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <joe@foo.bar>
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 à : <A3 01 .. .. > 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')
<detached_signature>
"@t" - Le texte signé suit.
Ceci émet le paquet de contrôle (2, 'B')
<signed_text>
"@." - 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 <user-name>
PUT
DELETE <user-name>
Le format de réponse utilisé est :
======
"GNUPG/1.0" status-code status-text
"Content-length:" digits
CRLF
============
suivi par <digits> 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=<stringlist>. 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/<gnupg_formatierte_user_id>?op=<operation>
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.