Le manuel de GNU Privacy Guard · PDF fileChapitre 1. Pour démarrer. d’essayer de...

Le manuel de GNU Privacy Guard

Le manuel de GNU Privacy GuardCopyright © 1999 The Free Software Foundation

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU FreeDocumentation License, Version 1.1 or any later version published by the Free Software Foundation; with noInvariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in thesection entitled "GNU Free Documentation License".

Merci d’envoyer les questions, suggestions et rapports de bug à propos de ce manuel au mainteneur, MikeAshley (<[email protected] >). Envoyez vos commentaires et vos corrections concernant la traduction àJean-François Paris (<[email protected] >). Merci de spécifier la version du manuel àlaquelle vous faîtes référence. Utilisez la référence suivante:$Name: fr_v1rc1 $ .

Matthew Copeland, Joergen Grahn, et David A. Wheeler ont contribué a la rédaction de ce manuel. J HoracioMG a traduit ce manuel en espagnol. Merci à l’équipe de traduction de l’ALDIL, à Frédéric Delanoy pour larelecture. Que ceux que j’aurai oublié se manifestent.

Table des matières1. Pour démarrer. ...................................................................................................................................................1

1.1. Générer une nouvelle paire de clés..........................................................................................................11.1.1. Générer un certificat de révocation.............................................................................................2

1.2. Échanger des clés....................................................................................................................................31.2.1. Exporter une clé publique...........................................................................................................31.2.2. Importer une clé publique...........................................................................................................3

1.3. Chiffrer et déchiffrer des documents.......................................................................................................41.4. Générer et vérifier des signatures............................................................................................................5

1.4.1. Les documents signés en clair....................................................................................................61.4.2. Signatures détachées...................................................................................................................6

2. Concepts..............................................................................................................................................................8

2.1. Algorithmes de chiffrement symétriques................................................................................................82.2. Procédés de chiffrement à clé publique...................................................................................................82.3. Procédés de chiffrement hybride.............................................................................................................92.4. Signatures numériques..........................................................................................................................10

3. La gestion des clés............................................................................................................................................12

3.1. Gérer votre paire de clés........................................................................................................................123.1.1. Intégrité des clés.......................................................................................................................133.1.2. Ajouter et supprimer des composantes à une clé......................................................................143.1.3. Révoquer les composants d’une clé..........................................................................................143.1.4. Mettre à jour la date d’expiration d’une clé..............................................................................16

3.2. Valider les clés des autres dans votre trousseau de clés publique.........................................................163.2.1. Confiance dans le propriétaire d’une clé..................................................................................163.2.2. Utiliser la confiance pour valider les clés.................................................................................18

3.3. Distribution de clés................................................................................................................................19

4. Utilisation quotidienne de GnuPG.................................................................................................................21

4.1. Définir vos besoins en matière de sécurité............................................................................................214.1.1. Choisir la taille des clés............................................................................................................214.1.2. Protéger votre clé privée...........................................................................................................224.1.3. Définition des dates d’expiration et utilisation des clés secondaires........................................234.1.4. Gérer votre toile de confiance...................................................................................................23

4.2. Construisez votre réseau de confiance...................................................................................................244.3. Utiliser GnuPG légalement...................................................................................................................25

5. Divers................................................................................................................................................................26

5.1. Écrire des interfaces utilisateur.............................................................................................................26

A. GNU Free Documentation License................................................................................................................28

0. PREAMBLE.............................................................................................................................................281. APPLICABILITY AND DEFINITIONS.................................................................................................282. VERBATIM COPYING...........................................................................................................................293. COPYING IN QUANTITY .....................................................................................................................294. MODIFICATIONS...................................................................................................................................295. COMBINING DOCUMENTS.................................................................................................................316. COLLECTIONS OF DOCUMENTS.......................................................................................................317. AGGREGATION WITH INDEPENDENT WORKS..............................................................................318. TRANSLATION......................................................................................................................................319. TERMINATION.......................................................................................................................................3210. FUTURE REVISIONS OF THIS LICENSE.........................................................................................32

iii

How to use this License for your documents...............................................................................................32

iv

Liste des illustrations3-1. Un exemple de toile de confiance...................................................................................................................19

v

Chapitre 1. Pour démarrer.GnuPG est un outil pour communiquer de manière sûre. Ce chapitre permet de couvrir l’ensemble desfonctionnalités importantes de GnuPG afin de pouvoir démarrer rapidement. Cela inclut la création, l’échange etla vérification des paires de clés, le chiffrement et le déchiffrement des documents, et pour finir l’authentificationavec des signatures numériques. Il ne traite pas en détail des concepts qui sont derrière la cryptographie à clépublique, le chiffrement et les signatures numériques. Ceci est traité au chapitre2. Il n’explique pas non pluscomment utiliser GnuPG de manière avisée. Ceci est traité aux chapitres3 et4.

GnuPG utilise la cryptographie à clé publique de façon à ce que les utilisateurs puissent communiquer demanière sûre. Dans un système à clé publique, chaque utilisateur possède une paire de clés constituée d’unecléprivéeet d’uneclé publique. La clé privée de l’utilisateur est gardée secrète, elle ne doit pas être révélée. La clépublique peut être distribuée à toute personne avec qui l’utilisateur souhaite communiquer. GnuPG utilise unsystème un peu plus sophistiqué dans lequel un utilisateur possède une paire de clés primaire et zéro ou plusieurspaires de clés additionnelles. La clé primaire et les clés additionnelles sont empaquetées pour faciliter la gestiondes clés. Un paquet de clés peut être dans la plupart des cas considéré comme une simple paire de clés.

1.1. Générer une nouvelle paire de clésL’option de ligne de commande--gen-key est utilisée pour créer une nouvelle paire de clés.

alice% gpg --gen-keygpg (GnuPG) 0.9.4; Copyright (C) 1999 Free Software Foundation, Inc.This program comes with ABSOLUTELY NO WARRANTY.This is free software, and you are welcome to redistribute itunder certain conditions. See the file COPYING for details.

Please select what kind of key you want:(1) DSA and ElGamal (default)(2) DSA (sign only)(4) ElGamal (sign and encrypt)

Your selection?

GnuPG est capable de créer de nombreux types différents de paires de clés, mais une paire de clés primaire doitêtre capable de générer des signatures. C’est la raison pour laquelle il n’y a que 3 choix possibles. Le choixnuméro 1 crée en fait deux paires de clés. La paire de clés de type DSA est la paire de clés primaire, utilisableseulement pour signer. Une paire de clés additionnelle de type ElGamal est aussi créée pour le chiffrement. Lechoix numéro 2 est similaire, à la différence que seule la paire de clés DSA est créée. Le choix numéro 41 créeune paire de clés ElGamal utilisable pour générer des signatures, mais aussi pour le chiffrement. Dans tous lescas, il est possible d’ajouter après coup des clés additionnelles pour le chiffrement et les signatures. Pour laplupart des utilisateurs, l’option par défaut est conseillée.

Vous devez aussi choisir une taille pour la clé. La taille d’une clé DSA doit être comprise entre 512 et 1024 bits,et la clé ElGamal peut être d’une taille quelconque. Cependant GnuPG requiert que toutes les clés aient une taillesupérieure ou égale à 768 bits. Par conséquent, si vous avez choisi le choix 1 et une taille de clé supérieure à1024 bits, la clé ElGamal sera de la taille demandée, mais la clé DSA sera de 1024 bits.

About to generate a new ELG-E keypair.minimum keysize is 768 bitsdefault keysize is 1024 bits

highest suggested keysize is 2048 bitsWhat keysize do you want? (1024)

Plus la clé est longue, plus elle sera résistante face à une attaque par la force brute, mais pour presque tous lesusages, la taille de clé par défaut est adéquate puisqu’il coûterait moins cher de contourner le chiffrement que

1

Chapitre 1. Pour démarrer.

d’essayer de le casser. De plus, le chiffrement et le déchiffrement seront d’autant plus longs que la taille de la cléaugmente, et une clé plus longue peut aussi influer sur la taille de la signature. Une fois choisie, la taille de la cléne peut être changée.

Enfin, vous devez choisir une date d’expiration. Si le choix 1 est fait, la date d’expiration sera valable pour lapaire de clés ElGamal et pour la paire de clés DSA.

Please specify how long the key should be valid.0 = key does not expire

<n> = key expires in n days<n>w = key expires in n weeks<n>m = key expires in n months<n>y = key expires in n years

Key is valid for? (0)

Pour la plupart des utilisateurs se satisferont d’une clé qui n’expire jamais. La date d’expiration doit être choisieavec soin, car, bien qu’il soit possible de la changer après que la clé ait été créée, il est difficile de faire parvenirla clé avec la date mise à jour aux utilisateurs qui possèdent déjà votre clé publique.

Vous devez fournir un identificateur d’utilisateur en plus des paramètres de la clé. Cet identificateur est utilisépour associer la clé créée avec une personne physique.

You need a User-ID to identify your key; the software constructs the user idfrom Real Name, Comment and Email Address in this form:

"Heinrich Heine (Der Dichter) <[email protected]>"

Real name:

Un seul identificateur d’utilisateur est créé au moment de la création de la clé, mais il est possible d’en créerd’autres. Si vous voulez utiliser la clé dans deux ou plusieurs contextes, par exemple comme un employée autravail et comme un activiste politique à côté. Une identité doit être créée avec soin, car elle ne peut plus êtreéditée ensuite.

GnuPG a besoin d’un mot de passe étendu2 pour protéger les parties privées de la clé primaire et les clésadditionnelles que vous avez en votre possession.

You need a Passphrase to protect your private key.

Enter passphrase:

Il n’y a pas de limite sur la taille du mot de passe étendu, et il doit être soigneusement choisi. Dans uneperspective de sécurité, le mot de passe utilisé pour déverrouiller la clé privée est l’un des points faibles deGnuPG (ainsi que des autres systèmes de chiffrement à clé publique) car il est la seule protection dont vousdisposez si un individu obtient votre clé privée. De manière idéale, le mot de passe étendu ne devrait pas utiliserdes mots du dictionnaire, et devrait mélanger la casse des caractères alphabétiques et aussi utiliser des caractèresnon alphabétiques. Un bon mot de passe est crucial pour une utilisation sûre de GnuPG.

1.1.1. Générer un certificat de révocationUne fois que votre paire de clés a été créée, vous devez immédiatement créer un certificat de révocation pour laclé principale en utilisant l’option--gen-revoke . Si vous oubliez votre mot de passe, ou si votre clé privée estcompromise ou perdue, ce certificat de révocation peut être publié pour notifier aux autres que votre clé publiquene doit plus être utilisée. On peut toujours se servir d’une clé publique révoquée pour vérifier des signatures quevous avez faites par le passé, mais on ne peut s’en servir pour chiffrer de nouveaux messages à votre attention.Cela n’affecte pas non plus votre capacité à déchiffrer les messages qui vous ont été adressés précédemment, sivous avez toujours accès à votre clé privée.

alice% gpg --output revoke.asc --gen-revoke mykey

2


[...]

L’argumentmykey doit être unidentificateur de clé, soit celui de la clé principale de votre paire de clés, soit unepartie d’un identificateur d’utilisateur qui identifie votre clé. Le certificat produit sera enregistré dans le fichierrevoke.asc . Si l’option --output est omis, le résultat de la commande sera écrit sur la sortie standard.Comme le certificat est court, vous pouvez souhaiter en imprimer une copie pour la stocker dans un endroit sûr,comme votre coffre à la banque. Le certificat ne doit pas être stocké dans un endroit où d’autres pourraientaccéder, car n’importe qui peut publier le certificat de révocation, rendant inutilisable la clé publiquecorrespondante.

1.2. Échanger des clésPour communiquer avec les autres, vous devez échanger vos clés publiques. Pour afficher la liste des clés devotre trousseau de clés publiques utilisez l’option de ligne de commandes--list-keys .

alice% gpg --list-keys/users/alice/.gnupg/pubring.gpg---------------------------------------pub 1024D/BB7576AC 1999-06-04 Alice (Judge) <[email protected]>sub 1024g/78E9A8FA 1999-06-04

1.2.1. Exporter une clé publiquePour envoyer votre clé publique à un correspondant, vous devez d’abord l’exporter en utilisant l’option de lignede commandes--export . Elle prend un argument supplémentaire : l’identificateur de la clé à exporter. Commeavec l’option--gen-revoke , soit l’identificateur de la clé, soit une partie de l’identificateur utilisateur peut êtreutilisé pour identifier la clé à exporter.

alice% gpg --output alice.gpg --export [email protected]

La clé est exportée dans un format binaire, mais ceci peut être problématique si la clé doit être envoyée par emailou publiée sur une page web. C’est pourquoi GnuPG supporte une option de ligne de commandes--armor 3 quiprovoque la génération des sorties dans un format ASCII-armored (blindage ASCII) similaire aux documentsencodés avec l’algorithme UUE. En général, toutes les sorties de GnuPG, comme par exemple clés, documentschiffrés, et signatures, peuvent être exportés dans le format ASCII-armored en ajoutant l’option--armor .

alice% gpg --armor --export [email protected] PGP PUBLIC KEY BLOCK-----Version: GnuPG v0.9.7 (GNU/Linux)Comment: For info see http://www.gnupg.org

[...]-----END PGP PUBLIC KEY BLOCK-----

1.2.2. Importer une clé publiqueUne clé publique peut être ajoutée à votre trousseau de clés publiques avec l’option--import .

alice% gpg --import blake.gpggpg: key 9E98BC16: public key importedgpg: Total number processed: 1gpg: imported: 1

3


alice% gpg --list-keys/users/alice/.gnupg/pubring.gpg---------------------------------------pub 1024D/BB7576AC 1999-06-04 Alice (Judge) <[email protected]>sub 1024g/78E9A8FA 1999-06-04

pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) <[email protected]>sub 1024g/5C8CBD41 1999-06-04

Une fois que la clé a été importée, elle devrait être validée. GnuPG utilise un modèle de confiance puissant etflexible qui ne requiert pas que vous validiez personnellement chaque clé que vous importez. Toutefois, certainesclés le nécessitent. Une clé peut être validée en vérifiant son empreinte. En la signant, vous certifiez que c’estune clé valide. L’empreinte d’une clé peut être visualisée rapidement avec l’option de ligne de commandes--fingerprint , mais pour certifier la clé, vous devez l’éditer.

alice% gpg --edit-key [email protected]

pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/qsub 1024g/5C8CBD41 created: 1999-06-04 expires: never(1) Blake (Executioner) <[email protected]>

Command> fprpub 1024D/9E98BC16 1999-06-04 Blake (Executioner) <[email protected]>

Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16

L’empreinte d’une clé est vérifiée avec le propriétaire de la clé. Ce peut être fait en personne, au téléphone, oupar tout autre moyen, du moment que vous pouvez garantir que vous communiquez bien avec le vrai propriétairede la clé. Si l’empreinte que vous obtenez est la même que celle que le propriétaire de la clé obtient, alors vouspouvez être sûr que vous avez une copie correcte de la clé.

Après avoir vérifié l’empreinte, vous pouvez signer la clé pour la valider. Étant donné que la vérification des clésest un point faible de la cryptographie à clé publique, vous devez être extrêmement prudent et toujours vérifierl’empreinte d’une clé avant de la signer.

Command> sign

pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/qFingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16

Blake (Executioner) <[email protected]>

Are you really sure that you want to sign this keywith your key: "Alice (Judge) <[email protected]>"

Really sign?

Une fois signée, vous pouvez vérifier la clé pour lister ses signatures et voir celle que vous avez ajoutée. Chaqueidentificateur d’utilisateur de la clé aura une ou plusieurs auto-signatures et aussi une signature pour chaqueutilisateur qui a validé cette clé.

Command> checkuid Blake (Executioner) <[email protected]>sig! 9E98BC16 1999-06-04 [self-signature]sig! BB7576AC 1999-06-04 Alice (Judge) <[email protected]>

4


1.3. Chiffrer et déchiffrer des documents.La clé publique et la clé privée ont toutes deux un rôle spécifique quand vous chiffrez et déchiffrez desdocuments. Une clé publique peut être vue comme un coffre fort ouvert. Quand un correspondant chiffre undocument en utilisant une clé publique, ce document est mis dans le coffre, celui-ci est fermé, et la serruretournée de nombreuses fois. La clé privée correspondante est la combinaison qui peut rouvrir le coffre et lire ledocument. En d’autres termes, seule la personne qui détient la clé privée peut lire le document chiffré en utilisantla clé publique associée.

La procédure pour chiffrer et déchiffrer les documents est semblable à ce modèle. Si vous voulez chiffrer unmessage pour Alice, vous le faites en utilisant la clé publique d’Alice, qui le déchiffre avec sa clé privée. Si ellevous envoie un message, elle le chiffre en utilisant votre clé publique, et vous le déchiffrez avec votre clé privée.

Pour chiffrer un document, il faut utiliser l’option--encrypt . Vous devez avoir la clé publique de tous lesdestinataires. Le programme attend le nom du document à chiffrer en entrée ; s’il est omis, il lit l’entrée standard.Le résultat chiffré est placé sur la sortie standard ou comme spécifié en utilisant l’option--output . En plus duchiffrement, le document est compressé pour plus de sécurité.

alice% gpg --output doc.gpg --encrypt --recipient [email protected] doc

L’option --recipient est utilisée une fois pour chaque destinataire du message, et prend un argumentsupplémentaire spécifiant la clé publique pour laquelle le document doit être chiffré. Le document chiffré peutseulement être déchiffré par quelqu’un possédant une clé privée qui correspond à une des clés publiques desdestinataires. En particulier, vous ne pouvez pas déchiffrer un document chiffré par vous, à moins que vous ayezinclus votre clé publique dans la liste des destinataires.

Pour déchiffrer un message, on utilise l’option--decrypt . Vous avez besoin de la clé privée pour laquelle lemessage a été chiffré. De la même manière que pour le chiffrement, le document à déchiffrer est l’entrée et ledocument déchiffré est la sortie.

blake% gpg --output doc --decrypt doc.gpg

You need a passphrase to unlock the secret key foruser: "Blake (Executioner) <[email protected]>"1024-bit ELG-E key, ID 5C8CBD41, created 1999-06-04 (main key ID 9E98BC16)

Enter passphrase:

Les documents peuvent aussi être chiffrés sans recourir à la cryptographie à clé publique. Au lieu de cela, vousutilisez un algorithme de chiffrement symétrique pour chiffrer le document. La clé utilisée pour l’algorithme dechiffrement symétrique est dérivée du mot de passe fourni au chiffrement du document, et pour une bonnesécurité, il ne doit pas être le même que celui que vous utilisez pour protéger votre clé publique. Le chiffrementsymétrique est utile quand le mot de passe n’a pas besoin d’être communiqué aux autres. Un document peut êtrechiffré avec un algorithme de chiffrement symétrique en utilisant l’option--symmetric .

alice% gpg --output doc.gpg --symmetric docEnter passphrase:

1.4. Générer et vérifier des signaturesUne signature numérique certifie et date un document. Si le document est modifié d’une quelconque manière,une vérification de la signature échouera. Un signature numérique peut servir les mêmes besoins qu’unesignature manuscrite, en outre elle ne peut pas être contrefaite. Les distributions du code source de GnuPG, parexemple sont signées de telle manière que les utilisateurs puissent vérifier qu’elles n’ont pas été modifiées depuisqu’elles ont été empaquetées.

5


La création et la vérification des signatures utilisent les paires de clés privée/publique pour une opérationdifférente du chiffrement et du déchiffrement. Une signature est créée en utilisant la clé privée du signataire. Lasignature est vérifiée en utilisant la clé publique correspondante. Par exemple, Alice utilisera sa propre clé privéepour signer numériquement sa dernière contribution au Journal de la Chimie Non Organique. L’éditeur quigérera sa soumission utilisera la clé publique d’Alice pour vérifier que l’article vient en effet d’Alice et qu’il n’apas été modifié depuis qu’elle l’a envoyé. Une conséquence de l’utilisation des signatures numériques est qu’ilest difficile d’infirmer que vous avez fait une signature numérique car cela impliquerait que votre clé privée a étécompromise.

L’option de ligne de commandes--sign est utilisée pour générer une signature numérique. Le document àsigner est l’entrée, et le document signé est la sortie.

alice% gpg --output doc.sig --sign doc

You need a passphrase to unlock the private key foruser: "Alice (Judge) <[email protected]>"1024-bit DSA key, ID BB7576AC, created 1999-06-04

Enter passphrase:

Le document est compressé avant d’être signé, et la sortie est au format binaire.

Pour un document signé donné, vous pouvez en vérifier la signature ou vérifier la signature et récupérer ledocument original. Pour vérifier la signature, utilisez l’option--verify . Pour vérifier la signature et extraire ledocument, utilisez l’option--decrypt . Le document à vérifier et à récupérer est l’entrée et le documentrécupéré est la sortie.

blake% gpg --output doc --decrypt doc.siggpg: Signature made Fri Jun 4 12:02:38 1999 CDT using DSA key ID BB7576ACgpg: Good signature from "Alice (Judge) <[email protected]>"

1.4.1. Les documents signés en clairUn usage commun des signatures numériques est de signer les soumissions sur USENET, ou les messages email.Dans une telle situation, il est inopportun de compresser le document quand on le signe. L’option--clearsign

entraîne que le document est suivi par une signature ASCII-armored, mais le document n’est pas modifié outremesure.

alice% gpg --clearsign doc

You need a passphrase to unlock the secret key foruser: "Alice (Judge) <[email protected]>"1024-bit DSA key, ID BB7576AC, created 1999-06-04

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1

[...]-----BEGIN PGP SIGNATURE-----Version: GnuPG v0.9.7 (GNU/Linux)Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k=y6kj-----END PGP SIGNATURE-----

6


1.4.2. Signatures détachéesUn document signé a une utilité limitée. Les autres utilisateurs doivent récupérer le document original à partir dela version signée, et même avec un document signé en clair, le document signé doit être modifié pour retrouverl’original. C’est pourquoi un troisième modèle de signature de document, crée une signature détachée du reste dudocument. Dans ce cas la signature est écrite dans un fichier séparé. Une signature détachée est créée en utilisantl’option --detach-sig .

alice% gpg --output doc.sig --detach-sig doc

You need a passphrase to unlock the secret key foruser: "Alice (Judge) <[email protected]>"1024-bit DSA key, ID BB7576AC, created 1999-06-04

Enter passphrase:

Le document et la signature détachée sont tous deux nécessaires pour vérifier la signature du document, à l’aidede l’option--verify .

blake% gpg --verify doc.sig docgpg: Signature made Fri Jun 4 12:38:46 1999 CDT using DSA key ID BB7576ACgpg: Good signature from "Alice (Judge) <[email protected]>"

Notes1. Le choix numéro 3 permet de générer une paire de clés ElGamal, qui n’est utilisable que pour le chiffrement

2. ndt : en anglais pass phrase

3. Les options de lignes de commandes fréquemment utilisées peuvent êtres spécifiées dans un fichier deconfiguration.

7

Chapitre 2. ConceptsGnuPG fait usage de nombreux concepts de cryptographie dont lesalgorithmes de chiffrement symétriques,algorithmes de chiffrement à clé publique, ethachage à sens unique. Il n’est pas nécessaire de comprendrecomplètement ces concepts pour utiliser les fonctionnalités de GnuPG.

Ce chapitre est une introduction aux concepts cryptographiques de base utilisés par GnuPG. D’autres livrescouvrent ces sujets plus en détails. Un bon livre pour approfondir cette étude est “Cryptographie Appliquée”(http://www.counterpane.com/applied.html) de Bruce Schneier (http://www.counterpane.com/schneier.html).

2.1. Algorithmes de chiffrement symétriques.Un algorithme de chiffrement symétrique utilise la même clé pour le chiffrement et le déchiffrement. Les deuxpartis qui veulent communiquer en utilisant un algorithme de chiffrement symétrique doivent au préalable semettre d’accord sur la clé. Une fois qu’elles le sont, l’émetteur chiffre le message en utilisant la clé, l’envoie audestinataire, et ce dernier le déchiffre en utilisant la même clé. Par exemple, la machine allemande Enigmautilisait un algorithme de chiffrement symétrique, et les clés quotidiennes étaient distribuées dans des livres decode. Chaque jour, les opérateurs radio qui émettaient ou recevaient devaient consulter leur copie du livre decodes, pour trouver la clé du jour. Le trafic radio pour la journée était chiffré et déchiffré en utilisant la clé dujour. Des exemples modernes d’algorithmes de chiffrement symétrique sont 3DES, Blowfish, ou IDEA.

Un bon procédé de chiffrement fait reposer la sécurité seulement sur la clef, nullement sur l’algorithme. End’autres termes, ce ne sera d’aucune aide à un éventuel cryptanaliste de connaître l’algorithme utilisé. Laconnaissance de l’algorithme est nécessaire seulement s’il a obtenu la clé. Les procédés de chiffrement utilisésdans GnuPG vérifient cette propriété.

Comme toute la sécurité repose sur la clé, il est très important qu’il soit très difficile de deviner la clé. Autrementdit, l’ensemble des clés possibles, c’est à direl’espace des clésse doit d’être grand. Lorsqu’il était à LosAlamos, Richard Feynman était célèbre pour sa capacité à forcer les coffres forts. Pour encourager le mythe, iltransportait presque toujours avec lui un ensemble d’outils incluant un vieux stéthoscope. En réalité, il utilisaitune quantité d’astuces pour réduire le nombre de combinaisons, il devait donc en essayer un petit nombre etcontinuait jusqu’à ce qu’il trouve la bonne. En d’autres termes, il réduisait la taille de l’espace des clés.

Les anglais utilisaient des machines pour découvrir les clés pendant la seconde guerre mondiale. La machineallemande Enigma avait un espace de clés très grand, mais les anglais ont construit des machines à calculerspécialisées dénommées les Bombes, pour essayer mécaniquement les clés, jusqu’à ce que la clé du jour soittrouvée. Cela signifie que parfois ils trouvaient la clé du jour pendant qu’elle était utilisée, mais cela signifieaussi que certains jours ils ne la trouvaient jamais. Les Bombes n’étaient pas des ordinateurs à proprement parler,mais étaient des précurseurs de nos ordinateurs modernes.

Aujourd’hui, les ordinateurs peuvent deviner des clés très rapidement : c’est la raison pour laquelle la taille desclés est très importante dans les cryptosystèmes modernes. Le procédé DES utilise une clé de 56 bits, ce quisignifie qu’il y a 256 clés possibles. 256 cela fait 72,057,594,037,927,936 clés. Cela fait beaucoup de clés, maispour un ordinateur de base, essayer l’ensemble des clés est une question de jours. Un ordinateur spécialisé peutle faire en quelques heures. D’un autre côté, les procédés de chiffrement qui ont été conçus plus récemment,comme 3DES, Blowfish ou IDEA utilisent tous une clé de 128 bits, ce qui signifie qu’il y a 2128 clés possibles.C’est beaucoup, beaucoup trop de clés, et même si tous les ordinateurs de la planète coopéraient, il faudraitencore plus de temps que l’âge de l’univers pour trouver la clé.

8

Chapitre 2. Concepts

2.2. Procédés de chiffrement à clé publique.Le principal problème avec les procédés de chiffrement symétriques n’est pas leur sécurité, mais l’échange desclés. Une fois que l’émetteur et le récepteur ont échangé les clés, elles peuvent être utilisées pour communiquerde manière sécurisée, mais quel canal de communication sûr peut être utilisé pour communiquer la cléelle-même ? En particulier, il serait probablement plus facile pour un attaquant de travailler à intercepter la cléque d’essayer toutes les clés de l’espace des clés. Un autre problème est le nombre de clés nécessaires. S’il y anpersonnes qui doivent communiquer, alorsn(n-1)/2clés sont nécessaires pour que chaque couple de personnespuisse communiquer de manière privée. C’est peut être possible pour un petit nombre de personnes, mais çadevient rapidement ingérable pour un grand groupe de personnes.

Les procédés de chiffrement à clé publique ont été inventés pour éviter entièrement ce problème d’échange desclés. Un procédé de chiffrement à clé publique utilise une paire de clés pour envoyer des messages. Les deux clésappartiennent à la personne qui reçoit le message. Une des clés est laclé publiqueet peut être donnée àn’importe qui. L’autre clé est laclé privéeet elle est gardée secrète par son propriétaire. L’émetteur chiffre unmessage en utilisant la clé publique et, une fois chiffré, seule la clé privée peut être utilisée pour le déchiffrer.

Ce protocole résout le problème d’échange des clés inhérent au procédé de chiffrement symétrique. Il n’est pasnécessaire pour l’émetteur et le récepteur de se mettre d’accord sur une clé. Il suffit qu’à un moment précédant lacommunication secrète, l’émetteur obtienne une copie de la clé publique du destinataire. De plus, la clé publiqued’une personne peut être utilisée par toute personne désirant communiquer avec elle. Donc seulesn paires declés sont nécessaires àn personnes pour qu’elles puissent communiquer secrètement entre elles.

Les procédés de chiffrement à clé publique sont basés sur des fonctions à trappes à sens unique. Une fonction àsens unique est une fonction qui est aisée à calculer, mais dont l’inverse est dur à calculer. Par exemple, il estfacile de multiplier deux nombres premiers entre eux pour obtenir un produit, mais il est difficile de factoriser unproduit en deux nombres premiers qui le composent. Une fonction à trappe à sens unique est similaire, saufqu’elle comporte en plus une trappe. C’est-à-dire que si une certaine information est connue, il devient facile decalculer l’inverse. Par exemple, si vous avez un nombre composé de deux facteurs premiers, alors laconnaissance de l’un des facteurs rend le calcul du second facile. Considérons un procédé de chiffrement à clépublique basé sur la factorisation en nombres premiers. La clé publique contient un nombre obtenu par le produitde deux nombres premiers très grands, et l’algorithme de chiffrement utilise ce nombre pour chiffrer le message.L’algorithme de déchiffrement du message nécessite de connaître les facteurs premiers, donc le déchiffrement estfacile si vous avez la clé privée contenant un des facteurs, mais extrêmement difficile si vous ne l’avez pas.

Comme avec un bon procédé de chiffrement symétrique, avec un bon procédé de chiffrement à clé publique, lasécurité repose entièrement sur la clé. C’est la raison pour laquelle la taille de la clé est une mesure de la sécuritédu système, mais on ne peut pas comparer la taille des clés d’un système de chiffrement symétrique et d’unsystème de chiffrement à clé publique comme une mesure de leur sécurité relative. Dans une attaque par la forcebrute sur un procédé symétrique, avec une taille de clé de 80 bits, l’attaquant doit énumérer jusqu’à 280 clés pourtrouver la bonne. Dans une attaque par la force brute sur un procédé à clé publique, avec une taille de clé de 512bits, l’attaquant doit factoriser un nombre encodé sur 512 bits (jusqu’à 155 chiffres). La charge de travail del’attaquant est fondamentalement différente suivant le procédé de chiffrement qu’il attaque. Alors que 128 bitssuffisent pour un procédé de chiffrement symétrique, étant donné la technologie de factorisation actuelle, desclés publiques de 1024 bits sont recommandées pour la plupart des usages.

2.3. Procédés de chiffrement hybrideLes procédés de chiffrement à clé publique ne sont pas la panacée. Beaucoup de procédés de chiffrementssymétriques sont plus résistants du point de vue de la sécurité et le chiffrement et le déchiffrement à clé publiquesont plus coûteux que les opérations correspondantes dans un système symétrique. Les procédés de chiffrement àclé publique sont néanmoins un outil efficace pour distribuer les clés des procédés symétriques, et c’est pourquoiils sont utilisés dans les procédés de chiffrement hybride.

9


Un procédé de chiffrement hybride utilise à la fois un procédé de chiffrement symétrique et à clé publique. Celafonctionne en utilisant un procédé de chiffrement à clé publique pour partager une clé qui sera utilisée pour leprocédé de chiffrement symétrique. Le vrai message envoyé est chiffré en utilisant la clé puis transmis audestinataire. Comme l’échange de clés symétriques est sécurisé, la clé symétrique utilisée est différente pourchaque message envoyé. C’est pour cela qu’elle est aussi parfois appelée clé de session.

PGP et GnuPG utilisent tous les deux des procédés de chiffrement hybride. La clé de session, chiffrée enutilisant le procédé de chiffrement à clé publique, et le message envoyé, chiffré en utilisant le procédé dechiffrement symétrique, sont automatiquement combinés en un paquet. Le destinataire utilise sa clé privée pourdéchiffrer la clé de session et la clé de session est ensuite utilisée pour déchiffrer le message.

Un procédé de chiffrement hybride est aussi résistant que le plus faible des procédés de chiffrement mis enœuvre. Dans PGP et GnuPG, le procédé de chiffrement à clé publique est probablement le plus faible des deux.Heureusement, même si un attaquant arrive à déchiffrer une clé de session, elle pourra seulement être utiliséepour lire le message qui a été chiffré avec cette clé de session. L’attaquant devra recommencer et déchiffrer uneautre clé de session pour lire un autre message.

2.4. Signatures numériquesUne fonction de hachage est une fonction plusieurs donne un qui transforme son entrée en une valeur inclusedans un ensemble fini. Typiquement cet ensemble est un champ de nombres naturels. Une fonction simple dehachage estf (x) = 0 pour tout entierx. Une fonction de hachage plus intéressante estf (x) = x mod37, qui faitcorrespondrex avec le reste de la division dex par 37.

La signature numérique d’un document est le résultat de l’application d’une fonction de hachage sur cedocument. Toutefois, pour être utile, la fonction de hachage doit vérifier deux propriétés importantes.Premièrement, il doit être difficile de trouver deux documents qui une fois hachés donnent la même valeur.Deuxièmement, pour une valeur résultant d’une fonction de hachage, il doit être difficile de retrouver ledocument qui a produit cette valeur.

Quelques procédés de chiffrement à clé publique1 peuvent être utilisés pour signer un document. Le signatairechiffre le document avec sa cléprivée. Toute personne désireuse de vérifier la signature et de voir le documentutilise simplement la clé publique du signataire pour déchiffrer le document. Cet algorithme satisfait les deuxpropriétés nécessaires pour une bonne fonction de hachage, mais en pratique, cet algorithme est trop lent pourêtre utile.

Une alternative est d’utiliser des fonctions de hachage conçues pour satisfaire ces deux propriétés importantes.SHA et MD5 sont des exemples de tels algorithmes. En utilisant un tel algorithme, un document est signé en lehachant et le résultat est la signature. Une autre personne peut vérifier la signature en hachant elle aussi sa copiedu document, et en comparant le résultat du hachage avec le résultat du hachage du document original. Si ellescorrespondent, il est presque certain que les documents sont identiques.

Le problème maintenant est comment utiliser une fonction de hachage pour faire des signatures numériques sanspermettre à un attaquant de fausser la vérification de la signature. Si le document et la signature sont envoyés nonchiffrés, un attaquant pourrait modifier le document et générer la signature correspondante sans que ledestinataire n’en soit conscient. Si le document seulement est chiffré, l’attaquant peut falsifier la signature etentraîner un échec de la vérification de la signature. Une troisième solution est d’utiliser un processus dechiffrement hybride à clé publique pour chiffrer à la fois le document et la signature. Le signataire utilise sa cléprivée, et n’importe qui peut utiliser sa clé publique pour vérifier la signature et le document. Cela semblecorrect, mais en fait ne l’est pas. Si cet algorithme sécurise vraiment le document, il le protège aussi contre lesaltérations et il n’y aurait plus de raison pour la signature. Plus important, ceci ne protège ni le document ni lasignature d’une altération. Avec cet algorithme, seule la clé de session pour le procédé de chiffrement symétriqueest chiffrée en utilisant la clé privée du signataire. N’importe qui peut utiliser la clé publique pour récupérer laclé de session. C’est la raison pour laquelle, il est facile pour un attaquant de récupérer la clé de session et de

10


l’utiliser pour chiffrer d’autres documents et les signatures correspondantes, et de les envoyer au nom del’émetteur.

Une solution consiste à utiliser un algorithme à clé publique pour chiffrer seulement la signature. La valeurretournée par la fonction de hachage est chiffrée en utilisant la clé privée du signataire, et n’importe qui peutvérifier la signature en utilisant sa clé publique. Le document signé peut être envoyé en clair si le document estpublic ou en utilisant d’autres algorithmes de chiffrement. Si le document est modifié, la vérification de lasignature va échouer, mais c’est précisément ce que la vérification d’une signature est censée détecter. Lestandard de signature numérique (DSA) est un algorithme de signature à clé publique qui fonctionne commecelui que l’on vient de décrire. DSA est l’algorithme de signature utilisé par défaut dans GnuPG.

Notes1. Le procédé doit avoir la propriété que la clé publique ou la clé privée peuvent être utilisées par l’algorithme

de chiffrement comme clé publique. RSA est un exemple d’un tel algorithme, alors qu’ElGamal ne l’est pas.

11

Chapitre 3. La gestion des clésLa falsification des clés est une faiblesse majeure de la sécurité des cryptosystèmes à clé publique. Un espionpeut falsifier les trousseaux de clés d’un utilisateur, ou fabriquer une clé publique pour un autre utilisateur et lapublier pour que d’autres la téléchargent et l’utilisent. Par exemple, supposons que Chloé veuille surveiller lesmessages qu’Alice envoie à Bob. Elle pourrait monter ce que l’on appelle une attaque del’homme au milieu.Pour cette attaque, Chloé crée une nouvelle paire de clés. Elle remplace la copie d’Alice de la clé publique deBob par la nouvelle clé publique. Ensuite elle intercepte les messages qu’Alice envoie à Bob. Pour chaquemessage intercepté, elle le déchiffre en utilisant la nouvelle clé privée, le chiffre en utilisant la clé publique deBob. Tous les messages envoyés par Alice à Bob peuvent maintenant être lus par Chloé.

Une bonne gestion des clés est cruciale pour être non seulement sûr de vos trousseaux de clés, mais aussi del’intégrité des trousseaux de clés des autres. Le coœ de la gestion des clés dans GnuPG est la notion de signaturedes clés. La signature des clés a deux buts principaux : elle vous permet de détecter la modification de votretrousseau de clés, et de certifier qu’une clé appartient vraiment à la personne dont le nom est inscrit dansl’identifiant de la clé. Les signatures de clés sont aussi utilisées dans un schéma connu sous le nom detoile deconfiance, utilisé pour étendre le mécanisme de certification aux clés qui ne sont pas signées directement parvous, mais par des gens en qui vous avez confiance. Les utilisateurs responsables qui pratiquent une bonnegestion des clés peuvent déjouer les attaques utilisant la falsification des clés.

3.1. Gérer votre paire de clésUne paire de clés possède une clé publique et une clé privée. Une clé publique consiste en la portion publique dela clé principale de signature, la portion publique des clés secondaires de chiffrement et de signature et lesidentifiants utilisés pour associer la clé publique à une personne réelle. Chaque partie de la clé possède desinformations sur elle même. Pour une clé, ces informations incluent ses identifiant d’utilisateurs, sa date decréation, sa date d’expiration, etc. Pour un identifiant, ces données incluent le nom de la personne réelle qu’elleidentifie, un commentaire1 optionnel et une adresse email. La structure d’une clé privée est similaire, exceptéqu’elle ne contient que les portions privées des clés, et qu’il n’y a pas d’informations concernant les identifiantsd’utilisateur.

L’option de ligne de commandes--edit-key peut être utilisée pour visualiser une paire de clés. Par exemple :

chloe% gpg --edit-key [email protected] key is available.

pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/usub 2048g/0CF8CB7A created: 1999-06-15 expires: neversub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14(1) Chloé (Jester) <[email protected]>(2) Chloé (Plebian) <[email protected]>Command>

La clé publique est affichée avec un drapeau indiquant si la clé privée est disponible. Les informations surchaque composant de la clé sont ensuite listées. La première colonne indique le type de la clé. Le mot clépub

identifie la clé publique principale de signature, et le mot clésub identifie une clé publique secondaire. Laseconde colonne indique la longueur de la clé en bits, son type et son identifiant. Le type estD pour une clé DSA,g pour une clé de chiffrement seul ElGamal, etGpour une clé ElGamal qui peut être utilisée pour le chiffrementet la signature. Les dates de création et d’expiration sont données aux colonnes trois et quatre. Les identifiantsd’utilisateur sont listés après les clés.

12

Chapitre 3. La gestion des clés

Plus d’informations sur la clé peuvent être obtenues avec les commandes interactives. La commandetogglebascule entre la composante privée et la composante publique de la paire de clés si elles sont effectivementdisponibles.

Command> toggle

sec 1024D/26B6AAE1 created: 1999-06-15 expires: neversbb 2048g/0CF8CB7A created: 1999-06-15 expires: neversbb 1792G/08224617 created: 1999-06-15 expires: 2002-06-14sbb 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14(1) Chloé (Jester) <[email protected]>(2) Chloé (Plebian) <[email protected]>

Les informations fournies sont similaires à celles affichées pour la clé publique. Le mot clésec identifie la cléprivée principale de signature, et le mot clésbb identifie les clés privées secondaires. Les identifiantsd’utilisateur de la clé publique associée sont aussi listés à sa convenance.

3.1.1. Intégrité des clésQuand vous distribuez votre clé publique, vous distribuez les composantes publiques de votre clé principale etdes clés secondaires qui lui sont associées, ainsi que les identifiants d’utilisateurs. Distribuer ces données seulesest cependant un risque pour la sécurité car il est possible pour un attaquant de falsifier la clé. La clé publiquepeut être modifiée en ajoutant ou en substituant des clés ou en changeant ou en ajoutant les identifiantsd’utilisateur. En modifiant l’identifiant d’utilisateur, l’attaquant peut changer son email et ainsi rediriger lesemails vers lui même. En changeant une des clés de chiffrement, l’attaquant peut être capable de déchiffrer lesmessages redirigés vers lui.

L’utilisation des signatures numériques permet de résoudre ce problème. Quand des données sont signées parune clé privée, la clé publique correspondante est liée aux données signées. En d’autres termes, seule la clépublique correspondante peut être utilisée pour vérifier la signature et vérifier que les données n’ont pas étémodifiées. Une clé publique peut être protégée contre les tentatives de falsification en utilisant la partie privée dela clé principale correspondante pour signer les composantes publiques et l’identifiant utilisateur. Elles serontainsi liées à la partie publique de la clé principale. Signer les composantes publiques de la clé avec la partieprivée de la clé principale est appelé uneauto-signature, et une clé publique qui a des identifiants utilisateurauto-signés ainsi liés à elle est appelée uncertificat.

Par exemple, Chloé a deux identifiants utilisateur et trois sous-clés. Les signatures des identifiants utilisateurspeuvent être vérifiées avec la commandecheckexécutée depuis le menu d’édition des clés.

chloe% gpg --edit-key chloeSecret key is available.

pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/usub 2048g/0CF8CB7A created: 1999-06-15 expires: neversub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14(1) Chloé (Jester) <[email protected]>(2) Chloé (Plebian) <[email protected]>

Command> checkuid Chloé (Jester) <[email protected]>sig! 26B6AAE1 1999-06-15 [self-signature]uid Chloé (Plebian) <[email protected]>sig! 26B6AAE1 1999-06-15 [self-signature]

Comme on aurait pu le deviner, la clé utilisée pour les signatures est la clé principale de signature qui portel’identifiant 0x26B6AAE1. Les auto-signatures des sous-clés sont présentes dans la clé publique, mais elle nesont pas affichées par l’interface de GnuPG.

13


3.1.2. Ajouter et supprimer des composantes à une cléVous pouvez rajouter des sous-clés et des identifiants d’utilisateur à votre paire de clés une fois qu’elle a étécréée. Un identifiant d’utilisateur est ajouté en utilisant la commandeadduid. On vous demande de saisir unnom, une adresse email et un commentaire comme lorsque vous avez créé votre paire de clés initiale. Unesous-clé est ajoutée en utilisant la commandeaddkey. L’interface est similaire à celle utilisée quand vous avezcréé votre paire de clés initiale. La sous-clé peut être une clé de signature DSA, une clé de chiffrement ElGamalou une clé ElGamal utilisable pour le chiffrement et les signatures. Lorsqu’une sous-clé ou un identifiantd’utilisateur est généré, ils sont signée en utilisant la clé principale de signature. C’est pour cette raison que vousdevez saisir votre mot de passe quand la sous-clé est générée.

Des identifiants d’utilisateur supplémentaires sont utiles quand vous avez besoin de multiples identités. Parexemple, vous pouvez avoir besoin d’une identité pour votre emploi et une pour votre engagement politique. Voscollègues de travail vous reconnaîtrons par l’identifiant d’utilisateur de votre emploi, les autres membres de votregroupe politique par l’identifiant d’utilisateur créé pour votre engagement politique. Étant donné que les deuxgroupes de personnes peuvent être totalement distincts, chaque groupe peut ne pas faire confiance à l’autreidentité d’utilisateur. C’est la raison pour laquelle les deux ID utilisateur sont nécessaires.

Les sous-clés supplémentaires sont aussi nécessaires. Les identifiants d’utilisateur associés à votre clé publiqueprincipale sont validés par les utilisateurs avec qui vous communiquez, et changer la clé principale nécessite derefaire les certifications. Ce peut être difficile et prendre beaucoup de temps si vous communiquez avec denombreuses personnes. D’un autre côté, il est recommandé de changer périodiquement les clés de chiffrement.Si la clé est cassée, toutes les données qui sont chiffrées avec elle sont vulnérables. Par contre, en changeant lesclés, seules les données chiffrées avec celle qui est cassée seront révélées.

Les sous-clés et les identifiants d’utilisateur peuvent aussi êtres effacés. Pour effacer une sous-clé ou unidentifiant d’utilisateur, vous devez d’abord le sélectionner en utilisant respectivement les commandeskey ouuid. Ces commandes sont des sélecteurs. Par exemple, la commandekey 2 sélectionne la deuxième sous-clé, etlancerkey 2 une seconde fois la désélectionne. Si aucun argument n’est fourni, toutes les sous-clés ou tous lesidentifiants d’utilisateur sont désélectionnés. Une fois que les identifiants d’utilisateur sont sélectionnés, lacommandedeluid efface l’identifiant d’utilisateur de votre clé. De manière similaire, la commandedelkeyefface toutes les sous-clés sélectionnées de votre clé publique et de votre clé privée.

Pour la gestion locale de clé, effacer les composantes des clés est un bon moyen de débarrasser les clés publiquesde ce qui n’est pas nécessaire. Effacer les identifiants d’utilisateur et les sous-clés de votre propre clé n’esttoutefois pas très avisé car cela complique la distribution des clés. Par défaut, quand un utilisateur importe votreclé publique mise à jour, elle sera fusionnée avec son ancienne copie de votre clé publique si elle était présentedans son trousseau de clés. Les composants des deux clés sont combinés lors de la fusion, et les composants quevous aviez effacés sont restaurés. Pour mettre à jour correctement la clé, l’utilisateur doit d’abord effacer lavieille version de votre clé et ensuite importer la nouvelle version. Cela fait du travail supplémentaire pour lespersonnes avec qui vous communiquez. De plus, si vous envoyez votre clé à un serveur de clés, la fusion a lieuquoi qu’il arrive, et toute personne qui téléchargera la clé depuis le serveur ne verra pas la clé avec lescomposants effacés. Par conséquent, pour mettre à jour votre clé, il vaut mieux révoquer les composants plutôtque de les effacer.

3.1.3. Révoquer les composants d’une cléPour révoquer une sous-clé , elle doit d’abord être sélectionnée. Une fois sélectionnée, elle peut être révoquéeavec la commanderevkey. La clé est révoquée en lui ajoutant une auto-signature de révocation. Contrairement àl’option de ligne de commandes--gen-revoke , l’effet est immédiat.

Command> revkeyDo you really want to revoke this key? y

14


You need a passphrase to unlock the secret key foruser: "Chloé (Jester) <[email protected]>"1024-bit DSA key, ID B87DBA93, created 1999-06-28

pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/usub 2048g/B7934539 created: 1999-06-28 expires: neversub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28rev! subkey has been revoked: 1999-06-29sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28(1) Chloé (Jester) <[email protected]>(2) Chloé (Plebian) <[email protected]>

Un identifiant d’utilisateur est révoqué de manière différente. Normalement, un identifiant d’utilisateurcollectionne des signatures qui attestent que celui-ci décrit bien la personne qui possède réellement la cléassociée. En théorie, un identifiant d’utilisateur décrit une personne pour toujours, car cette personne nechangera jamais. En pratique, certains éléments de l’identifiant d’utilisateur tels que son adresse email oud’autres composants peuvent changer avec le temps, rendant l’identifiant utilisateur invalide.

La spécification OpenPGP

* Première référence à OpenPGP

ne supporte pas la révocation des identifiant d’utilisateur, mais un identifiant d’utilisateur peut effectivement êtrerévoqué en révoquant l’auto-signature de celui-ci. Pour des raisons de sécurité décritesprécédemment, lescorrespondants ne feront pas confiance à un identifiant d’utilisateur sans auto-signature valide.

Une signature est révoquée en utilisant la commanderevsig. Comme vous pouvez avoir signé un nombrequelconque d’identifiants d’utilisateur, l’interface utilisateur vous demande de décider pour chaque signature sielle doit être révoquée ou non.

Command> revsigYou have signed these user IDs:

Chloé (Jester) <[email protected]>signed by B87DBA93 at 1999-06-28

Chloé (Plebian) <[email protected]>signed by B87DBA93 at 1999-06-28

user ID: "Chloé (Jester) <[email protected]>"signed with your key B87DBA93 at 1999-06-28Create a revocation certificate for this signature? (y/N)nuser ID: "Chloé (Plebian) <[email protected]>"signed with your key B87DBA93 at 1999-06-28Create a revocation certificate for this signature? (y/N)yYou are about to revoke these signatures:

Chloé (Plebian) <[email protected]>signed by B87DBA93 at 1999-06-28

Really create the revocation certificates? (y/N)y

You need a passphrase to unlock the secret key foruser: "Chloé (Jester) <[email protected]>"1024-bit DSA key, ID B87DBA93, created 1999-06-28

pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/usub 2048g/B7934539 created: 1999-06-28 expires: neversub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28rev! subkey has been revoked: 1999-06-29sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28(1) Chloé (Jester) <[email protected]>(2) Chloé (Plebian) <[email protected]>

Un identifiant d’utilisateur révoqué est indiqué par la signature de révocation sur l’identifiant d’utilisateur quandses signatures sont listées.

15


Command> checkuid Chloé (Jester) <[email protected]>sig! B87DBA93 1999-06-28 [self-signature]uid Chloé (Plebian) <[email protected]>rev! B87DBA93 1999-06-29 [revocation]sig! B87DBA93 1999-06-28 [self-signature]

Pour révoquer des sous-clés ou des auto-signatures d’un identifiant d’utilisateur, GnuPG ajoute desauto-signatures de révocation à la clé. Étant donné que des signatures sont ajoutées et que rien n’est effacé, unerévocation sera toujours visible par autrui quand votre clé publique mise à jour est distribuée et fusionnée avecd’anciennes copies de cette clé. C’est pourquoi la révocation garantit que tout le monde possède une copieintègre de votre clé publique.

3.1.4. Mettre à jour la date d’expiration d’une cléLa date d’expiration d’une clé peut être mise à jour avec la commandeexpire depuis le menu d’édition des clés.Si aucune clé est sélectionnée, c’est la date d’expiration de la clé principale qui est mise à jour. Dans les autrescas, la date d’expiration de la sous-clé sélectionnée est mise à jour.

La date d’expiration d’une clé est associée avec sa self-signature. La date d’expiration est mise à jour en effaçantl’ancienne self-signature et en ajoutant une nouvelle self-signature. Étant donné que les correspondants n’aurontpas effacé l’ancienne self-signature, ils verront une self-signature supplémentaire de la clé quand ils mettront àjour leur copie de la clé. La dernière self-signature fait référence, donc, vos correspondants pourront connaître demanière non ambiguë la date d’expiration de vos clé.

3.2. Valider les clés des autres dans votre trousseau de cléspubliqueDans le chapitre1 nous avons donné une procédure pour valider les clés publiques de vos correspondants : la clépublique d’un correspondant est validée en vérifiant personnellement l’empreinte de sa clé et en signant ensuitesa clé publique avec votre clé privée. En vérifiant personnellement l’empreinte vous pouvez être sûr que la clé luiappartient vraiment, et comme vous avez signé la clé, vous pouvez être sûr de détecter toute modification dans lefutur. Malheureusement, cette procédure est ingrate quand vous devez valider un grand nombre de clés ou quandvous devez communiquer avec des gens que vous ne connaissez pas personnellement.

GnuPG tente de résoudre ce problème avec un mécanisme connu sous le nom detoile de confiance2. Dans lemodèle de la toile de confiance, la responsabilité pour valider les clés publiques est déléguée aux personnes enqui vous avez confiance. Par exemple, supposons que

• Alice a signé la clé de Blake, et• Blake a signé les clés de Chloé et de Dharma.

Si Alice fait suffisamment confiance à Blake pour valider les clés qu’il signe, alors Alice considérera que les clésde Chloé et Dharma sont valides sans les avoir personnellement vérifiées. Elle utilise simplement sa copievalidée de la clé publique de Blake, pour vérifier que les signatures faites par Blake sur les clés de Chloé etDharma sont bonnes. En général, si on suppose qu’Alice fait confiance à tout le monde pour valider les clésqu’ils signent, alors toute clé signée par une clé valide est aussi considérée comme valide. La racine est la cléd’Alice, qui est considérée comme valide de manière axiomatique.

16


3.2.1. Confiance dans le propriétaire d’une cléEn pratique, la notion de confiance est subjective. Par exemple, la clé de Blake est valide pour Alice car elle l’asignée, mais elle peut aussi ne pas faire confiance à Blake pour valider les clés qu’il signe. Dans ce cas, elle neconsidérera pas les clés de Chloé est de Dharma comme valides en se basant seulement sur la signature de Blake.Le modèle de toile de confiance prend ceci en compte en associant à chaque clé publique de votre trousseau uneindication sur la manière dont vous faites confiance au propriétaire de la clé. Il y a quatre niveaux de confiance.

unknown

On ne sait rien sur la façon dont le propriétaire signe les clés. Les clés de votre trousseau de clés publiquesont par défaut ce niveau de confiance.

none

On sait que le propriétaire ne vérifie pas consciencieusement les clés avant de les signer.

marginal

Le propriétaire comprend l’implication de la signature des clés et valide les clés avant de les signer.

full

Le propriétaire comprend complètement les implications de la signature des clés, et sa signature sur une cléaurait la même valeur que votre signature.

Le niveau de confiance sur une clé est une chose personnelle que vous attribuez. Cette information est considéréecomme privée. Ce n’est pas empaqueté avec la clé lorsque vous l’exportez ; elle est même enregistréeséparément de vos trousseaux, dans une base de donnée distincte.

L’éditeur de clés de GnuPG peut être utilisé pour définir le niveau de confiance que vous avez dans lepropriétaire d’une clé. La commandetrust est utilisée pour ce faire. Dans cet exemple, Alice édite le niveau deconfiance qu’elle a en Blake et ensuite elle met à jour la base de données de confiance pour recalculer quellesclés sont valides en se basant sur le nouveau niveau de confiance assigné à Blake.

alice% gpg --edit-key blake

pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/fsub 1024g/C19EA233 created: 1999-07-02 expires: never(1) Blake (Executioner) <[email protected]>

Command> trustpub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/fsub 1024g/C19EA233 created: 1999-07-02 expires: never(1) Blake (Executioner) <[email protected]>

Please decide how far you trust this user to correctlyverify other users’ keys (by looking at passports,checking fingerprints from different sources...)?

1 = Don’t know2 = I do NOT trust3 = I trust marginally4 = I trust fullys = please show me more informationm = back to the main menu

Your decision? 3

pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: m/fsub 1024g/C19EA233 created: 1999-07-02 expires: never(1) Blake (Executioner) <[email protected]>

17


Command> quit[...]

Le niveau de confiance dans le propriétaire de la clé et la validité de la clé sont indiqués à droite quand le clé estaffichée. La confiance dans le propriétaire est affichée en premier et la validité de la clé est affichée ensuite3. Lesquatre niveaux utilisés pour spécifier la confiance et la validité sont : unknown (q), none (n), marginal (m), et full(f ). Dans ce cas, la clé de Blake est complètement valide car Alice l’a signée elle-même. Initialement laconfiance accordée à Blake pour signer la clé des autres était non déterminée, mais elle a décidé de lui fairemarginalement confiance.

3.2.2. Utiliser la confiance pour valider les clésLa toile de confiance autorise l’élaboration d’algorithmes plus élaborés pour valider une clé. Précédemment, uneclé était considérée comme valide si vous l’aviez signée personnellement. Un algorithme plus flexible peutmaintenant être utilisé : une cléK est considérée comme valide si elle remplit deux conditions :

1. elle est signée par suffisamment de clés valides, c’est-à-dire si

• vous l’avez signée personnellement• elle a été signée par une clé à laquelle vous accordez toute votre confiance• elle a été signée par trois clés auxquelles vous accordez une confiance marginale

2. le chemin des clés signées conduisant deK jusqu’à votre propre clé mesure moins de cinq étapes.

La longueur du chemin, le nombre de clés auxquelles vous accordez une confiance marginale, et le nombre declés auxquelles vous accordez une confiance totale nécessaire peuvent être modifiés. Les valeurs donnéesci-dessus sont les valeurs par défaut utilisées par GnuPG.

Figure 3-1montre un exemple de toile de confiance dont Alice est la racine. Le graphe illustre qui a signé lesclés de qui. Le tableau montre quelles clés Alice considère comme valides en se basant sur le niveau deconfiance qu’elle accorde aux autres membres de la toile.

* Bug potentiel: l’option de ligne de commande--completes-needed semble être ignorée quand on l’utilise conjointement

avec l’option--update-trustdb . Les valeurs sont prises correctement en compte si elles sont placées dans le fichier de

configuration.

L’exemple considère que deux clés auxquelles on fait marginalement confiance et une en laquelle on a totalementconfiance sont nécessaires pour valider une autre clé. La longueur maximum du chemin est fixée à trois.

Dans cet exemple, les clés de Blake et de Dharma sont toujours considérées comme valides, car elles sontsignées directement avec la clé d’Alice. La validité des autres clés dépend de la confiance. Dans le premier cas,Alice a complètement confiance en Dharma, ce qui entraîne que les clés de Chloé et de Francis sont considéréescomme valides. Dans le second exemple, Alice fait marginalement confiance à Blake et à Dharma. Étant donnéque deux clés auxquelles on a marginalement confiance sont nécessaires pour valider une clé, celle de Chloé seraconsidérée comme pleinement valide, mais celle de Francis sera considérée comme marginalement valide. Dansle cas où on a marginalement confiance dans les clés de Chloé et de Dharma, celle de Chloé sera marginalementvalide car celle de Dharma est pleinement valide. Toutefois, la clé de Francis sera considérée commemarginalement valide, car seule une clé valide peut être utilisée pour valider les autres clés, et la celle de Dharmaest la seule clé pleinement valide utilisée pour signer la clé de Francis. Si de plus on ajoute une confiancemarginale dans la clé de Blake, la clé de Chloé devient pleinement valide, et elle peut être utilisée pour validerpleinement la clé de Francis et valider marginalement la clé de Elena. Pour finir, même si on a pleinementconfiance dans les clés de Blake, Chloé et Elena, çà ne suffit pas pour valider la clé de Geoff, car la longueur

18


maximum du chemin pour valider une clé est de trois, alors que la longueur du chemin allant de la clé de Geoffjusqu’à celle d’Alice est de quatre.

Le modèle de toile de confiance est une approche flexible du problème de l’échange sécurisé de données avecdes clés publiques. Il vous permet de personnaliser GnuPG pour vos besoins personnels. D’un côté, vous pouvezinsister sur de multiples chemins courts allant de votre clé jusqu’à une autre cléK pour la valider. D’un autrecôté, vous pouvez être satisfait par des chemins plus longs et même par un seul chemin allant de votre cléjusqu’à l’autre cléK. Demander de nombreux chemins courts est une forte garantie que la cléK appartient bien àcelui à qui vous pensez qu’elle appartient. Ceci a un prix : il est plus difficile de valider les clés car vous devezsigner plus de clés que si vous acceptiez de moins nombreux chemins, et de plus courts chemins.

Figure 3-1. Un exemple de toile de confiance

confiance validité

marginale complète marginale complète

Dharma Blake, Chloé, Dharma,Francis

Blake, Dharma Francis Blake, Chloé, Dharma

Chloé, Dharma Chloé, Francis Blake, Dharma

Blake, Chloé, Dharma Elena Blake, Chloé, Dharma,Francis

Blake, Chloé, Elena Blake, Chloé, Elena,Francis

3.3. Distribution de clésDe manière idéale, vous devez distribuer vos clés en les donnant personnellement à vos correspondants. Parcontre, en pratique, les clés sont souvent distribuées par email, ou par d’autre moyens électroniques decommunication. La distribution par email est une bonne pratique quand vous avez seulement quelquescorrespondants, et même si vous avez de nombreux correspondants, vous pouvez utiliser d’autres moyenscomme diffuser votre clé publique sur votre page Web. Ceci n’est pas acceptable si des personnes qui ont besoinde votre clé publique ne savent pas où la trouver sur le Web.

Pour résoudre ce problème, des serveurs de clés publiques sont utilisés pour collecter et distribuer les cléspubliques. Une clé publique reçue par le serveur est soit ajoutée à la base de données du serveur soit fusionnéeavec la clé existante si elle est déjà présente. Quand une requête de clé arrive au serveur, ce dernier consulte sabase de données et renvoie la clé publique s’il la trouve.

19


L’utilisation d’un serveur de clés est aussi intéressante quand de nombreuses personnes signent fréquemment lesclés d’autres personnes. Sans l’utilisation d’un serveur de clés, quand Blake signe la clé d’Alice, il doit envoyer àAlice une copie de sa clé publique signée par lui pour qu’elle puisse ajouter la clé mise à jour à son trousseau, etla distribuer à tous ses correspondants. C’est la responsabilité de Alice et de Blake envers la communauté pourconstruire une toile de confiance resserrée et ainsi améliorer la sécurité de PGP. C’est néanmoins ennuyeux si lasignature des clés est fréquente.

L’utilisation d’un serveur de clés rend le procédé plus facile. Quand Blake signe la clé d’Alice, il envoie la clésignée au serveur. Le serveur de clé ajoute la signature de Blake à sa copie de la clé publique d’Alice. Lespersonnes qui veulent mettre à jour leur copie de la clé de Alice consultent le serveur de clés quand ils lesouhaitent pour récupérer la clé mise à jour. Alice n’est plus responsable de la distribution, et elle peut récupérerles signatures sur sa clé publique en interrogeant simplement le serveur de clés.

* --keyserver doit apparaître avant--send-key ou --recv-key . Il s’agit d’un bug.

Une ou plusieurs clés peuvent être envoyées à un serveur de clés en utilisant l’option de ligne de commandes--send-keys . Cette option prend un ou plusieurs sélecteurs de clés et envoie les clés spécifiées au serveur declés. Le serveur de clés auquel les clés sont envoyées est spécifié avec l’option de ligne de commandes--keyserver . De manière similaire, l’option de ligne de commandes--recv-keys est utilisée pour récupérerles clés depuis un serveur de clés, mais cette option requiert l’utilisation d’un ID de clé pour spécifier la clé.Dans l’exemple suivant, Alice met à jour sa clé publique avec les nouvelles signatures depuis le serveur de cléscertserver.pgp.com et envoie ensuite sa copie de la clé publique de Blake au même serveur de clés pour yajouter toute nouvelle signature qu’elle y aurait ajoutée.

alice% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576ACgpg: requesting key BB7576AC from certserver.pgp.com ...gpg: key BB7576AC: 1 new signature

gpg: Total number processed: 1gpg: new signatures: 1alice% gpg --keyserver certserver.pgp.com --send-key [email protected]: success sending to ’certserver.pgp.com’ (status=200)

Il existe de nombreux serveurs de clés populaires en service à travers le monde. Les serveurs de clés les plusimportants se synchronisent entre eux ; il est donc suffisant de sélectionner un serveur de clés proche de vous surl’Internet et de l’utiliser régulièrement pour envoyer et recevoir des clés.

Notes1. ndt : pourquoi pas votre surnom.

2. ndt : en anglais Web Of Trust

3. GnuPG utilise le mot “trust” pour signifier la confiance dans le propriétaire et la confiance dans la clé. Cecipeut être la source de confusion. Parfois la confiance dans le propriétaire est appeléeowner-trustpourmarquer la différence avec la confiance dans la clé. Dans ce manuel, “confiance” est utilisé pour signifier laconfiance dans le propriétaire de la clé, et “validité” est utilisé pour signifier le fait que la clé appartientvraiment à la personne associée avec l’identifiant d’utilisateur de la clé.

20

Chapitre 4. Utilisation quotidienne de GnuPGGnuPG est un outil complexe dont l’utilisation soulève des problèmes techniques, sociaux et légaux.Techniquement, il a été conçu pour être utilisé dans différentes situations nécessitant des besoins en sécuritécomplètement différents. Cela complique la gestion des clés. D’un point de vue social, utiliser GnuPG n’est pasune décision strictement personnelle. Pour utiliser effectivement GnuPG, les deux parties doivent l’utiliser. Enfin,en 1999, les lois régissant le chiffrement et en particulier si l’utilisation de logiciels tels que GnuPG est légale ounon, varient d’un pays à l’autre et sont actuellement débattues au sein de nombreux gouvernements nationaux.

Ce chapitre traite de ces problèmes. Il donne des conseils pratiques sur l’utilisation de GnuPG pour qu’ilsatisfasse vos besoins en matière de sécurité. Il explique aussi comment encourager vos correspondants à utiliserGnuPG pour communiquer de manière sécurisée. Finalement, le statut légal de GnuPG est décrit compte tenudes lois sur l’utilisation du chiffrement à travers le monde.

4.1. Définir vos besoins en matière de sécuritéGnuPG est un outil que vous utilisez pour protéger votre intimité. Votre intimité est protégée si vous pouvezcorrespondre avec les autres sans que des tiers puissent lire ces messages.

La façon dont vous devez utiliser GnuPG dépend de la détermination et des ressources de ceux qui peuventvouloir lire les messages que vous chiffrez. La tierce personne peut être un administrateur système peuscrupuleux qui regarde négligemment vos emails, ou alors un espion industriel qui essaye de récupérer lessecrets de votre compagnie, ou bien alors une agence gouvernementale qui essaye de vous poursuivre.L’utilisation de GnuPG pour vous protéger contre de l’espionnage occasionnel est différent de celle que vous enfaites pour vous protéger contre un adversaire déterminé. Votre but ultime est de rendre plus coûteux le fait derécupérer les données chiffrées que ce qu’elles valent effectivement.

Adapter l’utilisation de GnuPG à vos besoins se résume à quatre problèmes :

• choisir la taille de votre paire de clés,• protéger votre clé privée,• définir les dates d’expiration et l’utilisation des clés secondaires,• gérer votre toile de confiance.

Un taille de clé bien choisie vous protège contre une attaque par la force brute contre les messages chiffrés.Protéger votre clé privée empêche un attaquant d’utiliser simplement votre clé pour déchiffrer vos messages eten signer d’autres en votre nom. Gérer correctement votre toile de confiance empêche qu’un attaquant se fassepasser pour un de vos correspondants et s’interpose entre ce dernier et vous. Finalement, gérer ces différentsproblèmes en fonction de vos besoins en sécurité se résume à comment équilibrer la charge de travailsupplémentaire requise pour utiliser GnuPG avec la protection que cela vous apporte.

4.1.1. Choisir la taille des clésLe choix de la taille d’une clé dépend du type de clé. Dans OpenPGP, une paire de clés comporte souvent demultiples clés. Elle a au moins une clé principale pour les signatures, et probablement une ou plusieurs sous-clésadditionnelles pour le chiffrement. En utilisant les paramètres par défaut de GnuPG, la clé principale sera une cléDSA, et les clés secondaires seront des clés ElGamal.

DSA permet une taille de clé allant jusqu’à 1024 bits. Ce n’est pas particulièrement bon étant donné lestechniques de factorisation actuelles, mais c’est ce qui est spécifié par le standard. Vous devez choisir une cléDSA de 1024 bits, sans vous poser de question.

21

Chapitre 4. Utilisation quotidienne de GnuPG

A l’opposé, les clés ElGamal peuvent être de n’importe quelle taille. Étant donné que GnuPG utilise un systèmehybride de chiffrement à clé publique, la clé publique est utilisée pour chiffrer la clé de session de 128 bits, et laclé privée est utilisée pour la déchiffrer. Néanmoins la taille de la clé a des répercussions sur la vitesse dechiffrement et de déchiffrement car le coût de ces algorithmes croit de manière exponentielle avec la taille de laclé. Les clés plus grosses prennent aussi plus de temps à générer et nécessitent plus d’espace pour le stockage.En fin de compte, cela diminue l’apport de sécurité d’une clé plus longue. Pour finir, si la clé est suffisammentgrande pour résister à une attaque par la force brute, un espion aura sûrement recours à d’autres méthodes pourobtenir le texte déchiffré. Par exemple, il peut vous cambrioler chez vous ou au bureau ou vous agresser. Pourcette raison, 1024 bits est la taille de clé recommandée. Si vous avez vraiment besoin d’une clé plus grande, alorsvous connaissez sûrement déjà tout ça, et vous devriez plutôt consulter un expert en sécurité informatique.

4.1.2. Protéger votre clé privéeLa protection de votre clé privée est crucial pour bien utiliser GnuPG. Si quelqu’un obtient votre clé privée, alorstout ce qui a été chiffré à l’intention de cette clé pourra être déchiffré, et il pourra faire des signatures en votrenom. Si vous perdez votre clé privée, alors vous ne pourrez plus déchiffrer les documents chiffrés qui vous ontété envoyés ou qui vous seront envoyés, et vous ne pourrez plus signer de documents. Le fait de ne plus être leseul possesseur de votre clé privée est catastrophique.

Quelle que soit la façon dont vous utilisez GnuPG, vous devez sauvegarder lecertificat de révocationde votre clépublique et une copie de sauvegarde de votre clé publique sur un support protégé en écriture stocké dans un lieusûr. Par exemple, vous pouvez les graver sur un CD-ROM et les stocker dans un coffre à la banque dans uneenveloppe scellée. Vous pouvez aussi les enregistrer sur une disquette et les cacher dans votre maison. Quoi quevous fassiez, ils doivent être enregistrés sur un support qui doit être physiquement capable de les mémoriseraussi longtemps que vous souhaitez utiliser la clé, et vous devez par conséquent les stocker plus soigneusementque la clé que vous utilisez tous les jours.

Pour vous aider à sauvegarder votre clé, GnuPG ne l’écrit pas directement sur le disque. Elle est chiffrée enutilisant un procédé symétrique de chiffrement. C’est la raison pour laquelle vous avez besoin d’un mot de passepour accéder à la clé. De cette façon, un attaquant doit franchir deux barrières pour accéder à votre clé privée :(1) il doit s’emparer de la clé, et (2) il doit la déchiffrer.

Enregistrer de manière sûre votre clé privée est important, mais ceci a un prix. Idéalement, vous devez garder laclé privée sur un disque amovible protégé en écriture, comme une disquette, et vous devez l’utiliser sur unemachine mono-utilisateur déconnectée du réseau. C’est peut-être dur voire carrément impossible à faire pourvous. Par exemple, vous pouvez ne pas posséder votre propre ordinateur et vous devez utiliser un ordinateur autravail ou à l’école, ou cela peut signifier que vous devez déconnecter votre ordinateur du réseau chaque fois quevous voulez utiliser GnuPG.

Cela ne signifie pas que vous ne devez pas utiliser GnuPG. Cela signifie seulement que vous avez décidé que lesdonnées que vous protégez sont suffisamment importantes pour que vous les chiffriez, mais pas assez pourmettre en place des mesures pour rendre la première barrière plus résistante. C’est votre choix.

Un bon mot de passe est critique pour utiliser GnuPG. Un attaquant qui accède à votre clé privée doit outrepasserle chiffrement utilisé pour protéger cette clé. Au lieu d’utiliser la force brute pour trouver la clé, l’attaquantessayera sûrement de deviner le mot de passe.

Il est plus facile de deviner le mot de passe faible, que de deviner une clé aléatoire de 128-bits. Si le mot de passeest un mot, il est bien moins coûteux d’essayer tous les mots des dictionnaires de tous les langages du monde.Même si les lettres du mot sont permutées, par exemple k3wldood, il est encore moins coûteux d’essayer lesmots du dictionnaire avec un catalogue de permutations. Le problème est le même avec les citations. En général,les mots de passe basés sur le langage naturel sont des mots de passe faibles, car le langage naturel a beaucoupde redondance et peu d’entropie. Vous devez éviter le langage naturel si vous le pouvez.

22


Un mot de passe est bon si vous pouvez vous en rappeler et s’il est dur à deviner pour les autres. Il doit êtrecomposé de caractères issus de tout l’ensemble des caractères imprimables de votre clavier. Cela inclut lescaractères alphabétiques, les nombres, et les caractères spéciaux comme} ou | . Soyez créatif et passez un peude temps à considérer votre mot de passe, un bon choix est très important pour assurer votre protection.

4.1.3. Définition des dates d’expiration et utilisation des clés secondairesPar défaut, la création d’une nouvelle paire de clés génère une clé DSA principale pour les signatures et une clésecondaire ElGamal pour le chiffrement. C’est convenable, car le rôle des deux clés est différent, et pour cetteraison vous pouvez vouloir que les deux clés aient des durées de vie différentes. La clé principale est utiliséepour faire les signatures numériques, et elle accumule les signatures des autres qui confirment votre identité. Laclé pour le chiffrement est seulement utilisée pour déchiffrer les documents chiffrés qui vous sont envoyés. Engénéral, une signature numérique a une longue durée de vie, par exemple pour toujours, et vous pouvez aussi nepas vouloir perdre les signatures sur votre clé que vous avez mis si longtemps à accumuler. D’un autre côté, laclé secondaire pour le chiffrement peut changer de manière périodique pour plus de sécurité, car si une clé dechiffrement est cassée, l’attaquant peut lire tous les documents qui ont été chiffrés à destination de cette clé dansle passé ou qui le seront dans le futur.

Dans presque tous les cas, vous ne voudrez pas que votre clé principale expire. Il y a deux raisons pour lesquellesvous pouvez choisir une date d’expiration. Premièrement, vous pourriez vouloir que la clé ait une durée de vielimitée. Par exemple, elle peut être utilisée pour un évènement particulier comme une campagne politique et ellene sera d’aucune utilité quand la campagne sera finie. Une autre raison est que si vous perdez le contrôle de laclé et que vous n’avez pas de certificat de révocation, le fait d’avoir une date d’expiration sur la clé principalevous assure que la clé finira par ne plus pouvoir être utilisée.

Changer les clés secondaires de chiffrement coule de source, mais cela peut éventuellement poser un problème.Si vous générez une nouvelle paire de clés avec une date d’expiration pour la clé secondaire, cette clé secondairefinira par expirer. Peu avant son expiration, vous devez ajouter une nouvelle clé secondaire et publier votre clépublique que vous venez de mettre à jour. Une fois que la clé secondaire aura expiré, ceux qui désirentcommuniquer avec vous doivent récupérer la clé que vous venez de mettre à jour car ils ne pourront plus chiffrerdes messages à votre attention avec la clé expirée. Cela peut poser problème suivant la façon dont vous distribuezvotre clé. Heureusement, d’un autre côté, vous ne devez pas collecter de nouvelles signatures car la clésecondaire sera signée avec la clé principale, qui aura été précédemment validée par vos correspondants.

Cet inconvénient peut oui ou non valoir l’apport supplémentaire en sécurité que cela procure. Tout comme vous,un attaquant peut toujours lire tous les documents chiffrés à destination de la clé secondaire expirée. Changer laclé secondaire protège seulement les documents qui seront chiffrés ultérieurement. Pour lire les documentschiffrés avec la nouvelle clé secondaire, l’attaquant devra monter une nouvelle attaque telle que celle qu’il autilisée la première fois.

Pour finir, il n’y a aucune raison à avoir plus d’une clé secondaire de chiffrement valide dans une clé. En avoirplusieurs n’apporte aucune sécurité supplémentaire. Il peut bien sûr y avoir un nombre quelconque de clésexpirées dans une paire de clés donnée de manière à ce que les documents chiffrés dans le passé puissenttoujours être déchiffrés, mais à un moment donné on a besoin que d’une seule clé secondaire active.

4.1.4. Gérer votre toile de confianceLa gestion de votre toile de confiance, tout comme la protection de votre clé privée, est un des aspects del’utilisation de GnuPG. Il est nécessaire de trouver le juste équilibre entre la sécurité et la facilité d’utilisation. Sivous utilisez GnuPG pour vous protéger contre de l’espionnage ou une usurpation d’identité occasionnelle, vouspouvez accorder une confiance relative aux signatures faites par les autres. D’un autre côté, si vous avez à faire à

23


quelqu’un de déterminé à envahir votre vie privée, vous devez moins faire confiance aux signatures des autres, etpasser plus de temps à vérifier personnellement les signatures.

Quels que soient vos besoins en sécurité, vous deveztoujours être prudentlorsque vous signez la clé dequelqu’un d’autre. Il est égoïste de signer une clé en étant juste assez sûr de la validité de la clé pour satisfairevos propres besoins en matière de sécurité. D’autres, avec des besoins plus stricts, peuvent dépendre de votresignature. S’ils ne peuvent pas avoir confiance en vous, cela affaiblit la toile de confiance et la communicationentre les utilisateurs de GnuPG sera plus difficile. Soyez aussi prudent lorsque vous signez des clés que voussouhaiteriez que les autres le soient si vous deviez dépendre de leurs signatures.

Dans la pratique, la gestion de votre toile de confiance se réduit à attribuer un degré de confiance aux autres et àrégler les options--marginals-needed et --completes-needed . Toute clé que vous signezpersonnellement sera considérée comme valide, mais à part pour les petits groupes, il ne sera pas possible designer personnellement les clés de toutes les personnes avec lesquelles vous devez communiquer. C’est la raisonpour laquelle vous devez attribuer prudemment des niveaux de confiance.

Il est recommandé d’attribuer prudemment des niveaux de confiance et de faire attention lorsque vous réglez lesoptions pour définir la façon dont GnuPG validera les clés. Prenons un exemple concret : vous pouvez fairepleinement confiance à un groupe d’amis très proches que vous savez être prudents lorsqu’ils valident les clés, etaccorder une confiance limitée aux autres utilisateurs de votre trousseau. À partir de là, vous pouvez régler--completes-needed à 1 et --marginals-needed à 2. Si vous êtes plus concerné par votre sécurité, vouspouvez régler ces valeurs respectivement à1 et 3 ou à2 et 3. Si vous êtes moins sujet à des attaques concernantvotre vie privée ou que vous souhaitez seulement être raisonnablement sûr de la validité des clés, réglez cesvaleurs à1 et 1. En général, des nombres plus grands pour ces options signifient que plus de personnes serontnécessaires pour qu’une conspiration à votre égard puisse vous faire croire qu’une clé est valide alors qu’ellen’appartient pas à la personne que vous croyez.

4.2. Construisez votre réseau de confianceVouloir utiliser soi-même GnuPG ne suffit pas. Pour pouvoir communiquer de manière sécurisée avec d’autrespersonnes, vous devez avoir une toile de confiance. Toutefois, au premier abord c’est une tache décourageante.Les personnes avec qui vous communiquez doivent utiliser GnuPG1, et il doit y avoir suffisamment de signaturespour considérer ces clés comme valides. Il ne s’agit pas de problèmes techniques, mais de problèmes sociaux.Quoiqu’il en soit, vous devez dépasser ces problèmes si vous voulez utiliser GnuPG.

Quand vous commencez à utiliser GnuPG, il est important de réaliser que vous n’avez pas besoin decommuniquer de manière sécurisée avec tous vos correspondants. Commencez avec un petit nombre depersonnes, peut-être juste vous et un ou deux de vos amis qui veulent utiliser leur droit à la protection de leur vieprivée. Générez vos clés et signez mutuellement vos clés publiques. Ceci est votre toile de confiance initiale. Enfaisant ceci, vous apprécierez la valeur d’une toile de confiance, petite et robuste, et vous serez plus prudentquand vous agrandirez votre toile dans le futur.

En plus de votre toile de confiance initiale, vous pouvez souhaiter communiquer de manière sécurisée avecd’autres personnes qui utilisent GnuPG. Toutefois, ceci peut être gênant pour deux raisons : (1) on ne sait pastoujours quand quelqu’un utilise ou veut utiliser GnuPG et (2) si vous connaissez quelqu’un qui l’utilise, vousaurez encore des problèmes pour valider sa clé. La première raison à cela est que les gens ne font pas toujours dela publicité pour dire qu’ils utilisent GnuPG. Pour changer ce comportement, il faut montrer l’exemple etprévenir que vous utilisez GnuPG. Il y a au moins trois façons de le faire : vous pouvez signer les messages quevous envoyez aux autres ou que vous postez publiquement, vous pouvez diffuser votre clé publique sur votrepage web ou si vous avez mis votre clé sur un serveur de clés, vous pouvez ajouter l’identifiant de votre clé dansvotre signature d’email. Si vous promouvez votre clé, vous rendez la chose plus normale à accepter pour les

24


autres. De plus, il sera plus facile pour les autres de commencer à communiquer de manière sécurisée avec vouscar vous aurez pris l’initiative et rendu clair le fait que vous utilisez GnuPG.

Le problème de la validation des clés est plus difficile. Si vous ne connaissez pas personnellement la personne àqui appartient la clé que vous souhaitez signer, alors il n’est pas possible que vous signiez la clé vous-même.Vous devez vous reposer sur la signature des autres et espérer trouver une chaîne de signatures conduisant de laclé en question jusqu’à la vôtre. Pour avoir une chance de trouver une chaîne, vous devez prendre l’initiative etfaire signer votre clé par d’autres personnes ne faisant pas partie de votre toile de confiance initiale. Pouraccomplir ceci, participez à des "key signing parties". Si vous allez à une conférence, regardez à l’avance s’il y aune key signing party de prévue, et s’il n’y en a pas, proposez d’en organiser une(http://www.herrons.com/kb2nsx/keysign.html). Vous pouvez aussi être plus passif et avoir votre empreinte declé avec vous pour des échanges de clés plus impromptus. Dans une telle situation, la personne à qui vousdonnez l’empreinte la vérifiera et signera votre clé une fois qu’elle sera rentrée chez elle.

Gardez bien à l’esprit que tout ceci est optionnel. Vous n’êtes pas obligé de faire connaître votre clé ou de signerla clé des autres. La puissance de GnuPG réside dans le fait qu’il est suffisamment flexible pour s’adapter à vosbesoins en sécurité quels qu’ils soient. Toutefois, en réalité, vous devrez prendre l’initiative si vous voulezagrandir votre toile de confiance et utiliser GnuPG pour effectuer une partie satisfaisante de votrecommunication.

4.3. Utiliser GnuPG légalementLe statut légal du chiffrement de données varie d’un pays à l’autre, et les lois concernant le chiffrement évoluentrapidement. Bert-Japp Koops (http://rechten.kub.nl/koops/bertjaap.htm) tient à jour le Crypto Law Survey(http://rechten.uvt.nl/koops/cryptolaw/index.htm) auquel vous pouvez vous référer si vous souhaitez connaître lestatut légal du chiffrement dans votre pays.

Notes1. Dans cette partie, GnuPG fait référence à GnuPG en tant qu’implémentation de OpenPGP ou à toute autre

telle le produit PGP de NAI.

25

Chapitre 5. DiversCe chapitre traite de divers sujets qui ne pouvaient pas être classés ailleurs dans le manuel. Au fur et à mesureque des sujets sont ajoutés, ils pourront être rassemblés dans des chapitres. Si vous souhaitez voir traité un sujeten particulier, suggérez-le. Mieux encore, portez-vous volontaire pour écrire un premier brouillon concernant cesujet!

5.1. Écrire des interfaces utilisateurAlma Whitten (http://www.cs.cmu.edu/~alma) et Doug Tygar (http://www.cs.berkeley.edu/~tygar) ont réaliséune étude (http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98-155.html) sur l’interface utilisateur duPGP 5.0 de NAI et sont arrivés à la conclusion que pour un utilisateur débutant, PGP peut paraître confus etfrustrant. Dans leur étude sur des sujets humains, seuls quatre des douze sujets ont réussi à envoyer des mailschiffrés aux membres de leur équipe, et trois des douze ont envoyé le secret sans chiffrement. De plus, la moitiédes sujets avaient des connaissances techniques.

Ces résultats ne sont pas surprenants. PGP 5.0 a une jolie interface utilisateur qui est excellente si vous êtesfamilier avec la façon dont fonctionne le chiffrement à clé publique et le modèle de gestion des clés de la toile deconfiance de OpenPGP. Malheureusement, les utilisateurs débutants ne comprennent pas le chiffrement à clépublique et encore moins la gestion des clés, et l’interface utilisateur ne les aide pas beaucoup.

Si vous écrivez une interface utilisateur, vous devriez lire l’étude de Whitten et Tygar qui fournit descommentaires pour chacun des sujets du test, et ces détails sont très instructifs. Par exemple, il apparaît qu’unebonne partie des sujets croyaient qu’un message à envoyer devait être chiffré avec leur propre clé publique. En yréfléchissant, vous conviendrez que c’est une erreur facile à commettre. En général, les utilisateurs débutants ontdes difficultés pour comprendre les différents rôles des clés publiques et privées dans GnuPG. En tant queconcepteur d’interface graphique, vous devez essayer de rendre évident à tous moment quelle clé est utilisée.Vous pouvez aussi utiliser des assistants pour guider l’utilisateur lors des tâches ordinaires telle que la générationdes clés, à l’intérieur desquelles des étapes annexes comme la génération du certificat de révocation et laréalisation d’une copie de sauvegarde qui sont essentielles pour utiliser GnuPG correctement. Le rapportcomporte aussi les commentaires suivants :

• La sécurité est un objectif secondaire. Les utilisateurs veulent envoyer des mails, surfer, etc. Il ne faut pass’imaginer que les utilisateurs seront motivés pour lire les manuels ou rechercher des contrôles de sécurité.

• La sécurité d’un ordinateur sur un réseau est aussi bonne que celle de son composant le plus faible. Lesutilisateurs doivent être guidés pour considérer tous les aspects de leur sécurité, et surtout ne doivent pas êtresabandonnés à eux-mêmes pour procéder à des explorations aléatoires comme ils pourraient le faire avec untraitement de texte ou un tableur.

• Utilisez les mêmes termes pour décrire les mêmes choses. Ne pas utiliser alternativement des synonymescomme “chiffrer” et “encoder”.

• Pour des utilisateurs inexpérimentés, simplifiez les affichages. Trop d’informations peuvent masquerl’information la plus importante. Dans la configuration initiale, un écran pourrait se contenter de donner àl’utilisateur une idée correcte de la relation entre les clés publiques et les clés privées et lui expliquer commentles obtenir et les distribuer.

Concevoir une interface utilisateur efficace pour la gestion des clés est encore plus difficile. La toile de confiancede OpenPGP est malheureusement plutôt obscure. Par exemple, la spécification impose trois niveaux deconfiance pour un utilisateur : aucune, marginale et complète. La confiance effectivement accordée parl’utilisateur doit correspondre à un de ces trois niveaux. L’algorithme de validation des clés est difficile à

26

Chapitre 5. Divers

comprendre pour les utilisateurs non informaticiens, en particulier les notions de “marginals needed” et de“completes needed”. Étant donné que le modèle de toile de confiance est bien spécifié et qu’il ne peut êtrechangé, vous allez devoir faire de votre mieux pour concevoir une interface utilisateur qui puisse le clarifier pourl’utilisateur. Une importante amélioration serait par exemple de générer un schéma relatant la façon dont la clé aété validée quand l’utilisateur le demande. Le rapport fait les commentaires suivants :

• Les utilisateurs vont probablement avoir du mal à cerner la façon et le moment où accorder des permissions.

• Accordez une grande importance au fait que les utilisateurs comprennent suffisamment leur sécurité pour lesempêcher de commettre des erreurs qui pourraient leur coûter cher. De telles erreurs pourraient être : effaceraccidentellement leur clé privée, publier ou révoquer accidentellement une clé, oublier leur mot de passe, nepas sauvegarder leurs trousseaux.

27

Annexe A. GNU Free Documentation LicenseVersion 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USAEveryone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLEThe purpose of this License is to make a manual, textbook, or other written document "free" in the sense offreedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, eithercommercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to getcredit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be freein the same sense. It complements the GNU General Public License, which is a copyleft license designed for freesoftware.

We have designed this License in order to use it for manuals for free software, because free software needs freedocumentation: a free program should come with manuals providing the same freedoms that the software does.But this License is not limited to software manuals; it can be used for any textual work, regardless of subjectmatter or whether it is published as a printed book. We recommend this License principally for works whosepurpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONSThis License applies to any manual or other work that contains a notice placed by the copyright holder saying itcan be distributed under the terms of this License. The "Document", below, refers to any such manual or work.Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, eithercopied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusivelywith the relationship of the publishers or authors of the Document to the Document’s overall subject (or torelated matters) and contains nothing that could fall directly within that overall subject. (For example, if theDocument is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) Therelationship could be a matter of historical connection with the subject or with related matters, or of legal,commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of InvariantSections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, inthe notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whosespecification is available to the general public, whose contents can be viewed and edited directly andstraightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (fordrawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatictranslation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparentfile format whose markup has been designed to thwart or discourage subsequent modification by readers is notTransparent. A copy that is not "Transparent" is called "Opaque".

28

Annexe A. GNU Free Documentation License

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format,LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTMLdesigned for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be readand edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools arenot generally available, and the machine-generated HTML produced by some word processors for outputpurposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold,legibly, the material this License requires to appear in the title page. For works in formats which do not have anytitle page as such, "Title Page" means the text near the most prominent appearance of the work’s title, precedingthe beginning of the body of the text.

2. VERBATIM COPYINGYou may copy and distribute the Document in any medium, either commercially or noncommercially, providedthat this License, the copyright notices, and the license notice saying this License applies to the Document arereproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may notuse technical measures to obstruct or control the reading or further copying of the copies you make or distribute.However, you may accept compensation in exchange for copies. If you distribute a large enough number ofcopies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITYIf you publish printed copies of the Document numbering more than 100, and the Document’s license noticerequires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts:Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly andlegibly identify you as the publisher of these copies. The front cover must present the full title with all words ofthe title equally prominent and visible. You may add other material on the covers in addition. Copying withchanges limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, canbe treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as manyas fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include amachine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy apublicly-accessible computer-network location containing a complete Transparent copy of the Document, free ofadded material, which the general network-using public has access to download anonymously at no charge usingpublic-standard network protocols. If you use the latter option, you must take reasonably prudent steps, whenyou begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thusaccessible at the stated location until at least one year after the last time you distribute an Opaque copy (directlyor through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any largenumber of copies, to give them a chance to provide you with an updated version of the Document.

29


4. MODIFICATIONSYou may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3above, provided that you release the Modified Version under precisely this License, with the Modified Versionfilling the role of the Document, thus licensing distribution and modification of the Modified Version to whoeverpossesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those ofprevious versions (which should, if there were any, be listed in the History section of the Document). Youmay use the same title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of themodifications in the Modified Version, together with at least five of the principal authors of the Document(all of its principal authors, if it has less than five).

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use theModified Version under the terms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in theDocument’s license notice.

H. Include an unaltered copy of this License.

I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, newauthors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled"History" in the Document, create one stating the title, year, authors, and publisher of the Document asgiven on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

J.Preserve the network location, if any, given in the Document for public access to a Transparent copy of theDocument, and likewise the network locations given in the Document for previous versions it was based on.These may be placed in the "History" section. You may omit a network location for a work that waspublished at least four years before the Document itself, or if the original publisher of the version it refers togives permission.

K. In any section entitled "Acknowledgements" or "Dedications", preserve the section’s title, and preserve inthe section all the substance and tone of each of the contributor acknowledgements and/or dedications giventherein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Sectionnumbers or the equivalent are not considered part of the section titles.

M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.

N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections andcontain no material copied from the Document, you may at your option designate some or all of these sections asinvariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice.These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your ModifiedVersion by various parties--for example, statements of peer review or that the text has been approved by anorganization as the authoritative definition of a standard.

30


You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as aBack-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-CoverText and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If theDocument already includes a cover text for the same cover, previously added by you or by arrangement made bythe same entity you are acting on behalf of, you may not add another; but you may replace the old one, onexplicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names forpublicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTSYou may combine the Document with other documents released under this License, under the terms defined insection 4 above for modified versions, provided that you include in the combination all of the Invariant Sectionsof all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in itslicense notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may bereplaced with a single copy. If there are multiple Invariant Sections with the same name but different contents,make the title of each such section unique by adding at the end of it, in parentheses, the name of the originalauthor or publisher of that section if known, or else a unique number. Make the same adjustment to the sectiontitles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, formingone section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sectionsentitled "Dedications". You must delete all sections entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTSYou may make a collection consisting of the Document and other documents released under this License, andreplace the individual copies of this License in the various documents with a single copy that is included in thecollection, provided that you follow the rules of this License for verbatim copying of each of the documents inall other respects.

You may extract a single document from such a collection, and distribute it individually under this License,provided you insert a copy of this License into the extracted document, and follow this License in all otherrespects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKSA compilation of the Document or its derivatives with other separate and independent documents or works, in oron a volume of a storage or distribution medium, does not as a whole count as a Modified Version of theDocument, provided no compilation copyright is claimed for the compilation. Such a compilation is called an"aggregate", and this License does not apply to the other self-contained works thus compiled with the Document,on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document isless than one quarter of the entire aggregate, the Document’s Cover Texts may be placed on covers that surroundonly the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

31


8. TRANSLATIONTranslation is considered a kind of modification, so you may distribute translations of the Document under theterms of section 4. Replacing Invariant Sections with translations requires special permission from theircopyright holders, but you may include translations of some or all Invariant Sections in addition to the originalversions of these Invariant Sections. You may include a translation of this License provided that you also includethe original English version of this License. In case of a disagreement between the translation and the originalEnglish version of this License, the original English version will prevail.

9. TERMINATIONYou may not copy, modify, sublicense, or distribute the Document except as expressly provided for under thisLicense. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automaticallyterminate your rights under this License. However, parties who have received copies, or rights, from you underthis License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSEThe Free Software Foundation may publish new, revised versions of the GNU Free Documentation License fromtime to time. Such new versions will be similar in spirit to the present version, but may differ in detail to addressnew problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particularnumbered version of this License "or any later version" applies to it, you have the option of following the termsand conditions either of that specified version or of any later version that has been published (not as a draft) bythe Free Software Foundation. If the Document does not specify a version number of this License, you maychoose any version ever published (not as a draft) by the Free Software Foundation.

How to use this License for your documentsTo use this License in a document you have written, include a copy of the License in the document and put thefollowing copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under theterms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free SoftwareFoundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and withthe Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free DocumentationLicense".

If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant.If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST";likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples inparallel under your choice of free software license, such as the GNU General Public License, to permit their usein free software.

32

Le manuel de GNU Privacy Guard · PDF fileChapitre 1. Pour démarrer. d’essayer de...

Documents

Transcript of Le manuel de GNU Privacy Guard · PDF fileChapitre 1. Pour démarrer. d’essayer de...