mirror of
git://git.gnupg.org/gnupg.git
synced 2024-11-04 20:38:50 +01:00
946 lines
36 KiB
Plaintext
946 lines
36 KiB
Plaintext
|
|
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.
|