Le manuel de GNU Privacy Guard Copyright ? 1999 The Free Software Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Merci d'envoyer les questions, suggestions et rapports de bug propos de ce manuel au mainteneur, Mike Ashley (). Envoyez vos commentaires et vos corrections concernant la traduction Jean-Fran ois Paris (< paris.jean-francois@bigfoot.com>). Merci de sp cifier la version du manuel laquelle vous fa tes r f rence. Utilisez la r f rence suivante: $Name: $. Matthew Copeland, Joergen Grahn, et David A. Wheeler ont contribu a la r daction de ce manuel. J Horacio MG a traduit ce manuel en espagnol. Merci l' quipe de traduction de l'ALDIL, Fr d ric Delanoy pour la relecture. Que ceux que j'aurai oubli se manifestent. ------------------------------------------------------------------------------- Table des mati res 1. Pour d marrer. G n rer une nouvelle paire de cl s G n rer un certificat de r vocation changer des cl s Exporter une cl publique Importer une cl publique Chiffrer et d chiffrer des documents. G n rer et v rifier des signatures Les documents sign s en clair Signatures d tach es 2. Concepts Algorithmes de chiffrement sym triques. Proc d s de chiffrement cl publique. Proc d s de chiffrement hybride Signatures num riques 3. La gestion des cl s G rer votre paire de cl s Int grit des cl s Ajouter et supprimer des composantes une cl R voquer les composants d'une cl Mettre jour la date d'expiration d'une cl Valider les cl s des autres dans votre trousseau de cl s publique Confiance dans le propri taire d'une cl Utiliser la confiance pour valider les cl s Distribution de cl s 4. Utilisation quotidienne de GnuPG D finir vos besoins en mati re de s curit Choisir la taille des cl s Prot ger votre cl priv e D finition des dates d'expiration et utilisation des cl s secondaires G rer votre toile de confiance Construisez votre r seau de confiance Utiliser GnuPG l galement 5. Divers crire des interfaces utilisateur A. GNU Free Documentation License 0. PREAMBLE 1. APPLICABILITY AND DEFINITIONS 2. VERBATIM COPYING 3. COPYING IN QUANTITY 4. MODIFICATIONS 5. COMBINING DOCUMENTS 6. COLLECTIONS OF DOCUMENTS 7. AGGREGATION WITH INDEPENDENT WORKS 8. TRANSLATION 9. TERMINATION 10. FUTURE REVISIONS OF THIS LICENSE How to use this License for your documents Liste des illustrations 3-1. Un exemple de toile de confiance ------------------------------------------------------------------------------- Chapitre 1. Pour d marrer. GnuPG est un outil pour communiquer de mani re s re. Ce chapitre permet de couvrir l'ensemble des fonctionnalit s importantes de GnuPG afin de pouvoir d marrer rapidement. Cela inclut la cr ation, l' change et la v rification des paires de cl s, le chiffrement et le d chiffrement des documents, et pour finir l'authentification avec 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 chapitre 2. Il n'explique pas non plus comment utiliser GnuPG de mani re avis e. Ceci est trait aux chapitres 3 et 4. GnuPG utilise la cryptographie cl publique de fa on ce que les utilisateurs puissent communiquer de mani re s re. Dans un syst me cl publique, chaque utilisateur poss de une paire de cl s constitu e d'une cl priv e et d'une cl 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 un syst me un peu plus sophistiqu dans lequel un utilisateur poss de une paire de cl s primaire et z ro ou plusieurs paires de cl s additionnelles. La cl primaire et les cl s additionnelles sont empaquet es pour faciliter la gestion des cl s. Un paquet de cl s peut tre dans la plupart des cas consid r comme une simple paire de cl s. ------------------------------------------------------------------------------- G n rer une nouvelle paire de cl s L'option de ligne de commande --gen-key est utilis e pour cr er une nouvelle paire de cl s. alice% gpg --gen-key gpg (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 it under 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 choix num 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, utilisable seulement pour signer. Une paire de cl s additionnelle de type ElGamal est aussi cr e pour le chiffrement. Le choix num ro 2 est similaire, la diff rence que seule la paire de cl s DSA est cr e. Le choix num ro 4[1] cr e une paire de cl s ElGamal utilisable pour g n rer des signatures, mais aussi pour le chiffrement. Dans tous les cas, il est possible d'ajouter apr s coup des cl s additionnelles pour le chiffrement et les signatures. Pour la plupart 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 taille sup 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 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What 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 les usages, la taille de cl par d faut est ad quate puisqu'il co terait moins cher de contourner le chiffrement que 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 la paire 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 = key expires in n days w = key expires in n weeks m = key expires in n months 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 choisie avec soin, car, bien qu'il soit possible de la changer apr s que la cl ait t cr e, il est difficile de faire parvenir la 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 id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " 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 er d'autres. Si vous voulez utiliser la cl dans deux ou plusieurs contextes, par exemple comme un employ e au travail 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 tendu[2] pour prot ger les parties priv es de la cl primaire et les cl s additionnelles 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 une perspective de s curit , le mot de passe utilis pour d verrouiller la cl priv e est l'un des points faibles de GnuPG (ainsi que des autres syst mes de chiffrement cl publique) car il est la seule protection dont vous disposez si un individu obtient votre cl priv e. De mani re id ale, le mot de passe tendu ne devrait pas utiliser des mots du dictionnaire, et devrait m langer la casse des caract res alphab tiques et aussi utiliser des caract res non alphab tiques. Un bon mot de passe est crucial pour une utilisation s re de GnuPG. ------------------------------------------------------------------------------- G n rer un certificat de r vocation Une fois que votre paire de cl s a t cr e, vous devez imm diatement cr er un certificat de r vocation pour la cl principale en utilisant l'option --gen-revoke. Si vous oubliez votre mot de passe, ou si votre cl priv e est compromise ou perdue, ce certificat de r vocation peut tre publi pour notifier aux autres que votre cl publique ne doit plus tre utilis e. On peut toujours se servir d'une cl publique r voqu e pour v rifier des signatures que vous 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, si vous avez toujours acc s votre cl priv e. alice% gpg --output revoke.asc --gen-revoke mykey [...] L'argument mykey doit tre un identificateur de cl , soit celui de la cl principale de votre paire de cl s, soit une partie d'un identificateur d'utilisateur qui identifie votre cl . Le certificat produit sera enregistr dans le fichier revoke.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 pourraient acc der, car n'importe qui peut publier le certificat de r vocation, rendant inutilisable la cl publique correspondante. ------------------------------------------------------------------------------- changer des cl s Pour communiquer avec les autres, vous devez changer vos cl s publiques. Pour afficher la liste des cl s de votre 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) sub 1024g/78E9A8FA 1999-06-04 ------------------------------------------------------------------------------- Exporter une cl publique Pour envoyer votre cl publique un correspondant, vous devez d'abord l'exporter en utilisant l'option de ligne de commandes --export. Elle prend un argument suppl mentaire : l'identificateur de la cl exporter. Comme avec l'option --gen-revoke, soit l'identificateur de la cl , soit une partie de l'identificateur utilisateur peut tre utilis pour identifier la cl exporter. alice% gpg --output alice.gpg --export alice@cyb.org La cl est export e dans un format binaire, mais ceci peut tre probl matique si la cl doit tre envoy e par email ou publi e sur une page web. C'est pourquoi GnuPG supporte une option de ligne de commandes --armor[3] qui provoque la g n ration des sorties dans un format ASCII-armored (blindage ASCII) similaire aux documents encod s avec l'algorithme UUE. En g n ral, toutes les sorties de GnuPG, comme par exemple cl s, documents chiffr s, et signatures, peuvent tre export s dans le format ASCII-armored en ajoutant l'option --armor. alice% gpg --armor --export alice@cyb.org -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v0.9.7 (GNU/Linux) Comment: For info see http://www.gnupg.org [...] -----END PGP PUBLIC KEY BLOCK----- ------------------------------------------------------------------------------- Importer une cl publique Une cl publique peut tre ajout e votre trousseau de cl s publiques avec l'option --import. alice% gpg --import blake.gpg gpg: key 9E98BC16: public key imported gpg: Total number processed: 1 gpg: imported: 1 alice% gpg --list-keys /users/alice/.gnupg/pubring.gpg --------------------------------------- pub 1024D/BB7576AC 1999-06-04 Alice (Judge) sub 1024g/78E9A8FA 1999-06-04 pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) 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 et flexible qui ne requiert pas que vous validiez personnellement chaque cl que vous importez. Toutefois, certaines cl s le n cessitent. Une cl peut tre valid e en v rifiant son empreinte. En la signant, vous certifiez que c'est une 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 blake@cyb.org pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q sub 1024g/5C8CBD41 created: 1999-06-04 expires: never (1) Blake (Executioner) Command> fpr pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) 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, ou par tout autre moyen, du moment que vous pouvez garantir que vous communiquez bien avec le vrai propri taire de la cl . Si l'empreinte que vous obtenez est la m me que celle que le propri taire de la cl obtient, alors vous pouvez 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 s est un point faible de la cryptographie cl publique, vous devez tre extr mement prudent et toujours v rifier l'empreinte d'une cl avant de la signer. Command> sign pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16 Blake (Executioner) Are you really sure that you want to sign this key with your key: "Alice (Judge) " Really sign? Une fois sign e, vous pouvez v rifier la cl pour lister ses signatures et voir celle que vous avez ajout e. Chaque identificateur d'utilisateur de la cl aura une ou plusieurs auto-signatures et aussi une signature pour chaque utilisateur qui a valid cette cl . Command> check uid Blake (Executioner) sig! 9E98BC16 1999-06-04 [self-signature] sig! BB7576AC 1999-06-04 Alice (Judge) ------------------------------------------------------------------------------- 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 des documents. Une cl publique peut tre vue comme un coffre fort ouvert. Quand un correspondant chiffre un document en utilisant une cl publique, ce document est mis dans le coffre, celui-ci est ferm , et la serrure tourn e de nombreuses fois. La cl priv e correspondante est la combinaison qui peut rouvrir le coffre et lire le document. En d'autres termes, seule la personne qui d tient la cl priv e peut lire le document chiffr en utilisant la cl publique associ e. La proc dure pour chiffrer et d chiffrer les documents est semblable ce mod le. Si vous voulez chiffrer un message pour Alice, vous le faites en utilisant la cl publique d'Alice, qui le d chiffre avec sa cl priv e. Si elle vous 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 les destinataires. 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 du chiffrement, le document est compress pour plus de s curit . alice% gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc L'option --recipient est utilis e une fois pour chaque destinataire du message, et prend un argument suppl mentaire sp cifiant la cl publique pour laquelle le document doit tre chiffr . Le document chiffr peut seulement tre d chiffr par quelqu'un poss dant une cl priv e qui correspond une des cl s publiques des destinataires. En particulier, vous ne pouvez pas d chiffrer un document chiffr par vous, moins que vous ayez inclus 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 le message a t chiffr . De la m me mani re que pour le chiffrement, le document d chiffrer est l'entr e et le document d chiffr est la sortie. blake% gpg --output doc --decrypt doc.gpg You need a passphrase to unlock the secret key for user: "Blake (Executioner) " 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, vous utilisez un algorithme de chiffrement sym trique pour chiffrer le document. La cl utilis e pour l'algorithme de chiffrement sym trique est d riv e du mot de passe fourni au chiffrement du document, et pour une bonne s curit , il ne doit pas tre le m me que celui que vous utilisez pour prot ger votre cl publique. Le chiffrement sym trique est utile quand le mot de passe n'a pas besoin d' tre communiqu aux autres. Un document peut tre chiffr avec un algorithme de chiffrement sym trique en utilisant l'option --symmetric. alice% gpg --output doc.gpg --symmetric doc Enter passphrase: ------------------------------------------------------------------------------- G n rer et v rifier des signatures Une 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'une signature manuscrite, en outre elle ne peut pas tre contrefaite. Les distributions du code source de GnuPG, par exemple sont sign es de telle mani re que les utilisateurs puissent v rifier qu'elles n'ont pas t modifi es depuis qu'elles ont t empaquet es. La cr ation et la v rification des signatures utilisent les paires de cl s priv e/publique pour une op ration diff rente du chiffrement et du d chiffrement. Une signature est cr e en utilisant la cl priv e du signataire. La signature est v rifi e en utilisant la cl publique correspondante. Par exemple, Alice utilisera sa propre cl priv e pour signer num riquement sa derni re contribution au Journal de la Chimie Non Organique. L' diteur qui g rera sa soumission utilisera la cl publique d'Alice pour v rifier que l'article vient en effet d'Alice et qu'il n'a pas t modifi depuis qu'elle l'a envoy . Une cons quence de l'utilisation des signatures num riques est qu'il est 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 for user: "Alice (Judge) " 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 le document original. Pour v rifier la signature, utilisez l'option --verify. Pour v rifier la signature et extraire le document, utilisez l'option --decrypt. Le document v rifier et r cup rer est l'entr e et le document r cup r est la sortie. blake% gpg --output doc --decrypt doc.sig gpg: Signature made Fri Jun 4 12:02:38 1999 CDT using DSA key ID BB7576AC gpg: Good signature from "Alice (Judge) " ------------------------------------------------------------------------------- Les documents sign s en clair Un 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 outre mesure. alice% gpg --clearsign doc You need a passphrase to unlock the secret key for user: "Alice (Judge) " 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/i8HhbcOSKF4ELyQB1 oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k =y6kj -----END PGP SIGNATURE----- ------------------------------------------------------------------------------- Signatures d tach es Un document sign a une utilit limit e. Les autres utilisateurs doivent r cup rer le document original partir de la version sign e, et m me avec un document sign en clair, le document sign doit tre modifi pour retrouver l'original. C'est pourquoi un troisi me mod le de signature de document, cr e une signature d tach e du reste du document. Dans ce cas la signature est crite dans un fichier s par . Une signature d tach e est cr e en utilisant l'option --detach-sig. alice% gpg --output doc.sig --detach-sig doc You need a passphrase to unlock the secret key for user: "Alice (Judge) " 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'aide de l'option --verify. blake% gpg --verify doc.sig doc gpg: Signature made Fri Jun 4 12:38:46 1999 CDT using DSA key ID BB7576AC gpg: Good signature from "Alice (Judge) " ------------------------------------------------------------------------------- Chapitre 2. Concepts GnuPG fait usage de nombreux concepts de cryptographie dont les algorithmes de chiffrement sym triques, algorithmes de chiffrement cl publique, et hachage sens unique. Il n'est pas n cessaire de comprendre compl 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 livres couvrent ces sujets plus en d tails. Un bon livre pour approfondir cette tude est ``Cryptographie Appliqu e'' de Bruce Schneier. ------------------------------------------------------------------------------- Algorithmes de chiffrement sym triques. Un algorithme de chiffrement sym trique utilise la m me cl pour le chiffrement et le d chiffrement. Les deux partis qui veulent communiquer en utilisant un algorithme de chiffrement sym trique doivent au pr alable se mettre d'accord sur la cl . Une fois qu'elles le sont, l' metteur chiffre le message en utilisant la cl , l'envoie au destinataire, et ce dernier le d chiffre en utilisant la m me cl . Par exemple, la machine allemande Enigma utilisait un algorithme de chiffrement sym trique, et les cl s quotidiennes taient distribu es dans des livres de code. Chaque jour, les op rateurs radio qui mettaient ou recevaient devaient consulter leur copie du livre de codes, pour trouver la cl du jour. Le trafic radio pour la journ e tait chiffr et d chiffr en utilisant la cl du jour. 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. En d'autres termes, ce ne sera d'aucune aide un ventuel cryptanaliste de conna tre l'algorithme utilis . La connaissance de l'algorithme est n cessaire seulement s'il a obtenu la cl . Les proc d s de chiffrement utilis s dans 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 . Autrement dit, l'ensemble des cl s possibles, c'est dire l'espace des cl s se doit d' tre grand. Lorsqu'il tait Los Alamos, Richard Feynman tait c l bre pour sa capacit forcer les coffres forts. Pour encourager le mythe, il transportait presque toujours avec lui un ensemble d'outils incluant un vieux st thoscope. En r alit , il utilisait une quantit d'astuces pour r duire le nombre de combinaisons, il devait donc en essayer un petit nombre et continuait 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 machine allemande Enigma avait un espace de cl s tr s grand, mais les anglais ont construit des machines calculer sp cialis es d nomm es les Bombes, pour essayer m caniquement les cl s, jusqu' ce que la cl du jour soit trouv e. Cela signifie que parfois ils trouvaient la cl du jour pendant qu'elle tait utilis e, mais cela signifie aussi 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 des cl s est tr s importante dans les cryptosyst mes modernes. Le proc d DES utilise une cl de 56 bits, ce qui signifie qu'il y a 2^56 cl s possibles. 2^56 cela fait 72,057,594,037,927,936 cl s. Cela fait beaucoup de cl s, mais pour un ordinateur de base, essayer l'ensemble des cl s est une question de jours. Un ordinateur sp cialis peut le 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 2^128 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 faudrait encore plus de temps que l' ge de l'univers pour trouver la cl . ------------------------------------------------------------------------------- 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 des cl s. Une fois que l' metteur et le r cepteur ont chang les cl s, elles peuvent tre utilis es pour communiquer de 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 a n personnes qui doivent communiquer, alors n(n-1)/2 cl s sont n cessaires pour que chaque couple de personnes puisse communiquer de mani re priv e. C'est peut tre possible pour un petit nombre de personnes, mais a devient 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 des cl s. Un proc d de chiffrement cl publique utilise une paire de cl s pour envoyer des messages. Les deux cl s appartiennent la personne qui re oit le message. Une des cl s est la cl publique et peut tre donn e n'importe qui. L'autre cl est la cl priv e et elle est gard e secr te par son propri taire. L' metteur chiffre un message 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 pas n cessaire pour l' metteur et le r cepteur de se mettre d'accord sur une cl . Il suffit qu' un moment pr c dant la communication secr te, l' metteur obtienne une copie de la cl publique du destinataire. De plus, la cl publique d'une personne peut tre utilis e par toute personne d sirant communiquer avec elle. Donc seules n paires de cl 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 est facile de multiplier deux nombres premiers entre eux pour obtenir un produit, mais il est difficile de factoriser un produit en deux nombres premiers qui le composent. Une fonction trappe sens unique est similaire, sauf qu'elle comporte en plus une trappe. C'est- -dire que si une certaine information est connue, il devient facile de calculer l'inverse. Par exemple, si vous avez un nombre compos de deux facteurs premiers, alors la connaissance 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 produit de 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 est facile 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, la s 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'un syst me de chiffrement cl publique comme une mesure de leur s curit relative. Dans une attaque par la force brute sur un proc d sym trique, avec une taille de cl de 80 bits, l'attaquant doit num rer jusqu' 2^ 80 cl s pour trouver la bonne. Dans une attaque par la force brute sur un proc d cl publique, avec une taille de cl de 512 bits, l'attaquant doit factoriser un nombre encod sur 512 bits (jusqu' 155 chiffres). La charge de travail de l'attaquant est fondamentalement diff rente suivant le proc d de chiffrement qu'il attaque. Alors que 128 bits suffisent pour un proc d de chiffrement sym trique, tant donn la technologie de factorisation actuelle, des cl s publiques de 1024 bits sont recommand es pour la plupart des usages. ------------------------------------------------------------------------------- Proc d s de chiffrement hybride Les proc d s de chiffrement cl publique ne sont pas la panac e. Beaucoup de proc d s de chiffrements sym triques sont plus r sistants du point de vue de la s curit et le chiffrement et le d chiffrement cl publique sont 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 pourquoi ils sont utilis s dans les proc d s de chiffrement hybride. Un proc d de chiffrement hybride utilise la fois un proc d de chiffrement sym trique et cl publique. Cela fonctionne en utilisant un proc d de chiffrement cl publique pour partager une cl qui sera utilis e pour le proc d de chiffrement sym trique. Le vrai message envoy est chiffr en utilisant la cl puis transmis au destinataire. Comme l' change de cl s sym triques est s curis , la cl sym trique utilis e est diff rente pour chaque 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 en utilisant le proc d de chiffrement cl publique, et le message envoy , chiffr en utilisant le proc d de chiffrement sym trique, sont automatiquement combin s en un paquet. Le destinataire utilise sa cl priv e pour d 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 e pour lire le message qui a t chiffr avec cette cl de session. L'attaquant devra recommencer et d chiffrer une autre cl de session pour lire un autre message. ------------------------------------------------------------------------------- Signatures num riques Une fonction de hachage est une fonction plusieurs donne un qui transforme son entr e en une valeur incluse dans un ensemble fini. Typiquement cet ensemble est un champ de nombres naturels. Une fonction simple de hachage est f(x) = 0 pour tout entier x. Une fonction de hachage plus int ressante est f(x) = x mod 37, qui fait correspondre x avec le reste de la division de x par 37. La signature num rique d'un document est le r sultat de l'application d'une fonction de hachage sur ce document. 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 le document qui a produit cette valeur. Quelques proc d s de chiffrement cl publique[4] peuvent tre utilis s pour signer un document. Le signataire chiffre le document avec sa cl priv e. Toute personne d sireuse de v rifier la signature et de voir le document utilise simplement la cl publique du signataire pour d chiffrer le document. Cet algorithme satisfait les deux propri 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 le hachant et le r sultat est la signature. Une autre personne peut v rifier la signature en hachant elle aussi sa copie du document, et en comparant le r sultat du hachage avec le r sultat du hachage du document original. Si elles correspondent, 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 sans permettre un attaquant de fausser la v rification de la signature. Si le document et la signature sont envoy s non chiffr s, un attaquant pourrait modifier le document et g n rer la signature correspondante sans que le destinataire n'en soit conscient. Si le document seulement est chiffr , l'attaquant peut falsifier la signature et entra ner un chec de la v rification de la signature. Une troisi me solution est d'utiliser un processus de chiffrement 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 semble correct, mais en fait ne l'est pas. Si cet algorithme s curise vraiment le document, il le prot ge aussi contre les alt rations et il n'y aurait plus de raison pour la signature. Plus important, ceci ne prot ge ni le document ni la signature d'une alt ration. Avec cet algorithme, seule la cl de session pour le proc d de chiffrement sym trique est chiffr e en utilisant la cl priv e du signataire. N'importe qui peut utiliser la cl publique pour r cup rer la cl de session. C'est la raison pour laquelle, il est facile pour un attaquant de r cup rer la cl de session et de l'utiliser pour chiffrer d'autres documents et les signatures correspondantes, et de les envoyer au nom de l' metteur. Une solution consiste utiliser un algorithme cl publique pour chiffrer seulement la signature. La valeur retourn e par la fonction de hachage est chiffr e en utilisant la cl priv e du signataire, et n'importe qui peut v rifier la signature en utilisant sa cl publique. Le document sign peut tre envoy en clair si le document est public ou en utilisant d'autres algorithmes de chiffrement. Si le document est modifi , la v rification de la signature va chouer, mais c'est pr cis ment ce que la v rification d'une signature est cens e d tecter. Le standard de signature num rique (DSA) est un algorithme de signature cl publique qui fonctionne comme celui que l'on vient de d crire. DSA est l'algorithme de signature utilis par d faut dans GnuPG. ------------------------------------------------------------------------------- Chapitre 3. La gestion des cl s La falsification des cl s est une faiblesse majeure de la s curit des cryptosyst mes cl publique. Un espion peut falsifier les trousseaux de cl s d'un utilisateur, ou fabriquer une cl publique pour un autre utilisateur et la publier pour que d'autres la t l chargent et l'utilisent. Par exemple, supposons que Chlo veuille surveiller les messages qu'Alice envoie Bob. Elle pourrait monter ce que l'on appelle une attaque de l'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 de Bob par la nouvelle cl publique. Ensuite elle intercepte les messages qu'Alice envoie Bob. Pour chaque message intercept , elle le d chiffre en utilisant la nouvelle cl priv e, le chiffre en utilisant la cl publique de Bob. 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 de l'int grit des trousseaux de cl s des autres. Le co? de la gestion des cl s dans GnuPG est la notion de signature des cl s. La signature des cl s a deux buts principaux : elle vous permet de d tecter la modification de votre trousseau de cl s, et de certifier qu'une cl appartient vraiment la personne dont le nom est inscrit dans l'identifiant de la cl . Les signatures de cl s sont aussi utilis es dans un sch ma connu sous le nom de toile de confiance, utilis pour tendre le m canisme de certification aux cl s qui ne sont pas sign es directement par vous, mais par des gens en qui vous avez confiance. Les utilisateurs responsables qui pratiquent une bonne gestion des cl s peuvent d jouer les attaques utilisant la falsification des cl s. ------------------------------------------------------------------------------- G rer votre paire de cl s Une paire de cl s poss de une cl publique et une cl priv e. Une cl publique consiste en la portion publique de la cl principale de signature, la portion publique des cl s secondaires de chiffrement et de signature et les identifiants utilis s pour associer la cl publique une personne r elle. Chaque partie de la cl poss de des informations sur elle m me. Pour une cl , ces informations incluent ses identifiant d'utilisateurs, sa date de cr ation, sa date d'expiration, etc. Pour un identifiant, ces donn es incluent le nom de la personne r elle qu'elle identifie, un commentaire[5] 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 identifiants d'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 chloe@cyb.org Secret key is available. pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u sub 2048g/0CF8CB7A created: 1999-06-15 expires: never sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14 sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14 (1) Chlo (Jester) (2) Chlo (Plebian) Command> La cl publique est affich e avec un drapeau indiquant si la cl priv e est disponible. Les informations sur chaque 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. La seconde colonne indique la longueur de la cl en bits, son type et son identifiant. Le type est D pour une cl DSA, g pour une cl de chiffrement seul ElGamal, et G pour une cl ElGamal qui peut tre utilis e pour le chiffrement et la signature. Les dates de cr ation et d'expiration sont donn es aux colonnes trois et quatre. Les identifiants d'utilisateur sont list s apr s les cl s. Plus d'informations sur la cl peuvent tre obtenues avec les commandes interactives. La commande toggle bascule entre la composante priv e et la composante publique de la paire de cl s si elles sont effectivement disponibles. Command> toggle sec 1024D/26B6AAE1 created: 1999-06-15 expires: never sbb 2048g/0CF8CB7A created: 1999-06-15 expires: never sbb 1792G/08224617 created: 1999-06-15 expires: 2002-06-14 sbb 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14 (1) Chlo (Jester) (2) Chlo (Plebian) 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 identifiants d'utilisateur de la cl publique associ e sont aussi list s sa convenance. ------------------------------------------------------------------------------- Int grit des cl s Quand vous distribuez votre cl publique, vous distribuez les composantes publiques de votre cl principale et des cl s secondaires qui lui sont associ es, ainsi que les identifiants d'utilisateurs. Distribuer ces donn es seules est cependant un risque pour la s curit car il est possible pour un attaquant de falsifier la cl . La cl publique peut tre modifi e en ajoutant ou en substituant des cl s ou en changeant ou en ajoutant les identifiants d'utilisateur. En modifiant l'identifiant d'utilisateur, l'attaquant peut changer son email et ainsi rediriger les emails vers lui m me. En changeant une des cl s de chiffrement, l'attaquant peut tre capable de d chiffrer les messages redirig s vers lui. L'utilisation des signatures num riques permet de r soudre ce probl me. Quand des donn es sont sign es par une 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 de la cl principale correspondante pour signer les composantes publiques et l'identifiant utilisateur. Elles seront ainsi li es la partie publique de la cl principale. Signer les composantes publiques de la cl avec la partie priv e de la cl principale est appel une auto-signature, et une cl publique qui a des identifiants utilisateur auto-sign s ainsi li s elle est appel e un certificat. Par exemple, Chlo a deux identifiants utilisateur et trois sous-cl s. Les signatures des identifiants utilisateurs peuvent tre v rifi es avec la commande check ex cut e depuis le menu d' dition des cl s. chloe% gpg --edit-key chloe Secret key is available. pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u sub 2048g/0CF8CB7A created: 1999-06-15 expires: never sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14 sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14 (1) Chlo (Jester) (2) Chlo (Plebian) Command> check uid Chlo (Jester) sig! 26B6AAE1 1999-06-15 [self-signature] uid Chlo (Plebian) 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 porte l'identifiant 0x26B6AAE1. Les auto-signatures des sous-cl s sont pr sentes dans la cl publique, mais elle ne sont pas affich es par l'interface de GnuPG. ------------------------------------------------------------------------------- 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 commande adduid. On vous demande de saisir un nom, une adresse email et un commentaire comme lorsque vous avez cr votre paire de cl s initiale. Une sous-cl est ajout e en utilisant la commande addkey. L'interface est similaire celle utilis e quand vous avez cr votre paire de cl s initiale. La sous-cl peut tre une cl de signature DSA, une cl de chiffrement ElGamal ou une cl ElGamal utilisable pour le chiffrement et les signatures. Lorsqu'une sous-cl ou un identifiant d'utilisateur est g n r , ils sont sign e en utilisant la cl principale de signature. C'est pour cette raison que vous devez 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. Par exemple, vous pouvez avoir besoin d'une identit pour votre emploi et une pour votre engagement politique. Vos coll gues de travail vous reconna trons par l'identifiant d'utilisateur de votre emploi, les autres membres de votre groupe politique par l'identifiant d'utilisateur cr pour votre engagement politique. tant donn que les deux groupes de personnes peuvent tre totalement distincts, chaque groupe peut ne pas faire confiance l'autre identit 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 publique principale sont valid s par les utilisateurs avec qui vous communiquez, et changer la cl principale n cessite de refaire les certifications. Ce peut tre difficile et prendre beaucoup de temps si vous communiquez avec de nombreuses 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 les cl 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 un identifiant d'utilisateur, vous devez d'abord le s lectionner en utilisant respectivement les commandes key ou uid. Ces commandes sont des s lecteurs. Par exemple, la commande key 2 s lectionne la deuxi me sous-cl , et lancer key 2 une seconde fois la d s lectionne. Si aucun argument n'est fourni, toutes les sous-cl s ou tous les identifiants d'utilisateur sont d s lectionn s. Une fois que les identifiants d'utilisateur sont s lectionn s, la commande deluid efface l'identifiant d'utilisateur de votre cl . De mani re similaire, la commande delkey efface 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 publiques de ce qui n'est pas n cessaire. Effacer les identifiants d'utilisateur et les sous-cl s de votre propre cl n'est toutefois pas tr s avis car cela complique la distribution des cl s. Par d faut, quand un utilisateur importe votre cl publique mise jour, elle sera fusionn e avec son ancienne copie de votre cl publique si elle tait pr sente dans son trousseau de cl s. Les composants des deux cl s sont combin s lors de la fusion, et les composants que vous aviez effac s sont restaur s. Pour mettre jour correctement la cl , l'utilisateur doit d'abord effacer la vieille version de votre cl et ensuite importer la nouvelle version. Cela fait du travail suppl mentaire pour les personnes avec qui vous communiquez. De plus, si vous envoyez votre cl un serveur de cl s, la fusion a lieu quoi qu'il arrive, et toute personne qui t l chargera la cl depuis le serveur ne verra pas la cl avec les composants effac s. Par cons quent, pour mettre jour votre cl , il vaut mieux r voquer les composants plut t que de les effacer. ------------------------------------------------------------------------------- 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 e avec la commande revkey. 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> revkey Do you really want to revoke this key? y You need a passphrase to unlock the secret key for user: "Chlo (Jester) " 1024-bit DSA key, ID B87DBA93, created 1999-06-28 pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u sub 2048g/B7934539 created: 1999-06-28 expires: never sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28 rev! subkey has been revoked: 1999-06-29 sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28 (1) Chlo (Jester) (2) Chlo (Plebian) Un identifiant d'utilisateur est r voqu de mani re diff rente. Normalement, un identifiant d'utilisateur collectionne 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 ne changera jamais. En pratique, certains l ments de l'identifiant d'utilisateur tels que son adresse email ou d'autres composants peuvent changer avec le temps, rendant l'identifiant utilisateur invalide. La sp cification OpenPGP ne supporte pas la r vocation des identifiant d'utilisateur, mais un identifiant d'utilisateur peut effectivement tre r voqu en r voquant l'auto-signature de celui-ci. Pour des raisons de s curit d crites pr c demment, les correspondants ne feront pas confiance un identifiant d'utilisateur sans auto-signature valide. Une signature est r voqu e en utilisant la commande revsig. Comme vous pouvez avoir sign un nombre quelconque d'identifiants d'utilisateur, l'interface utilisateur vous demande de d cider pour chaque signature si elle doit tre r voqu e ou non. Command> revsig You have signed these user IDs: Chlo (Jester) signed by B87DBA93 at 1999-06-28 Chlo (Plebian) signed by B87DBA93 at 1999-06-28 user ID: "Chlo (Jester) " signed with your key B87DBA93 at 1999-06-28 Create a revocation certificate for this signature? (y/N)n user ID: "Chlo (Plebian) " signed with your key B87DBA93 at 1999-06-28 Create a revocation certificate for this signature? (y/N)y You are about to revoke these signatures: Chlo (Plebian) signed by B87DBA93 at 1999-06-28 Really create the revocation certificates? (y/N)y You need a passphrase to unlock the secret key for user: "Chlo (Jester) " 1024-bit DSA key, ID B87DBA93, created 1999-06-28 pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u sub 2048g/B7934539 created: 1999-06-28 expires: never sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28 rev! subkey has been revoked: 1999-06-29 sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28 (1) Chlo (Jester) (2) Chlo (Plebian) Un identifiant d'utilisateur r voqu est indiqu par la signature de r vocation sur l'identifiant d'utilisateur quand ses signatures sont list es. Command> check uid Chlo (Jester) sig! B87DBA93 1999-06-28 [self-signature] uid Chlo (Plebian) 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 des auto-signatures de r vocation la cl . tant donn que des signatures sont ajout es et que rien n'est effac , une r vocation sera toujours visible par autrui quand votre cl publique mise jour est distribu e et fusionn e avec d'anciennes copies de cette cl . C'est pourquoi la r vocation garantit que tout le monde poss de une copie int gre de votre cl publique. ------------------------------------------------------------------------------- Mettre jour la date d'expiration d'une cl La date d'expiration d'une cl peut tre mise jour avec la commande expire 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 autres cas, 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 ant l'ancienne self-signature et en ajoutant une nouvelle self-signature. tant donn que les correspondants n'auront pas 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 de mani re non ambigu la date d'expiration de vos cl . ------------------------------------------------------------------------------- Valider les cl s des autres dans votre trousseau de cl s publique Dans le chapitre 1 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 ensuite sa cl publique avec votre cl priv e. En v rifiant personnellement l'empreinte vous pouvez tre s r que la cl lui appartient vraiment, et comme vous avez sign la cl , vous pouvez tre s r de d tecter toute modification dans le futur. Malheureusement, cette proc dure est ingrate quand vous devez valider un grand nombre de cl s ou quand vous 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 de toile de confiance[6]. Dans le mod le de la toile de confiance, la responsabilit pour valider les cl s publiques est d l gu e aux personnes en qui 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 s de Chlo et Dharma sont valides sans les avoir personnellement v rifi es. Elle utilise simplement sa copie valid e de la cl publique de Blake, pour v rifier que les signatures faites par Blake sur les cl s de Chlo et Dharma sont bonnes. En g n ral, si on suppose qu'Alice fait confiance tout le monde pour valider les cl s qu'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. ------------------------------------------------------------------------------- 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'a sign e, mais elle peut aussi ne pas faire confiance Blake pour valider les cl s qu'il signe. Dans ce cas, elle ne consid 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 une indication 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 publiques ont 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 e comme priv e. Ce n'est pas empaquet avec la cl lorsque vous l'exportez ; elle est m me enregistr e s 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 le propri taire d'une cl . La commande trust est utilis e pour ce faire. Dans cet exemple, Alice dite le niveau de confiance qu'elle a en Blake et ensuite elle met jour la base de donn es de confiance pour recalculer quelles cl 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/f sub 1024g/C19EA233 created: 1999-07-02 expires: never (1) Blake (Executioner) Command> trust pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f sub 1024g/C19EA233 created: 1999-07-02 expires: never (1) Blake (Executioner) Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources...)? 1 = Don't know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully s = please show me more information m = back to the main menu Your decision? 3 pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: m/f sub 1024g/C19EA233 created: 1999-07-02 expires: never (1) Blake (Executioner) 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 est affich e. La confiance dans le propri taire est affich e en premier et la validit de la cl est affich e ensuite[7]. Les quatre 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 la confiance accord e Blake pour signer la cl des autres tait non d termin e, mais elle a d cid de lui faire marginalement confiance. ------------------------------------------------------------------------------- Utiliser la confiance pour valider les cl s La toile de confiance autorise l' laboration d'algorithmes plus labor s pour valider une cl . Pr c demment, une cl tait consid r e comme valide si vous l'aviez sign e personnellement. Un algorithme plus flexible peut maintenant 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 de K 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 de cl s auxquelles vous accordez une confiance totale n cessaire peuvent tre modifi s. Les valeurs donn es ci-dessus sont les valeurs par d faut utilis es par GnuPG. Figure 3-1 montre un exemple de toile de confiance dont Alice est la racine. Le graphe illustre qui a sign les cl s de qui. Le tableau montre quelles cl s Alice consid re comme valides en se basant sur le niveau de confiance qu'elle accorde aux autres membres de la toile. L'exemple consid re que deux cl s auxquelles on fait marginalement confiance et une en laquelle on a totalement confiance 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 sont sign 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 es comme 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 sera consid r e comme pleinement valide, mais celle de Francis sera consid r e comme marginalement valide. Dans le cas o on a marginalement confiance dans les cl s de Chlo et de Dharma, celle de Chlo sera marginalement valide car celle de Dharma est pleinement valide. Toutefois, la cl de Francis sera consid r e comme marginalement valide, car seule une cl valide peut tre utilis e pour valider les autres cl s, et la celle de Dharma est la seule cl pleinement valide utilis e pour signer la cl de Francis. Si de plus on ajoute une confiance marginale dans la cl de Blake, la cl de Chlo devient pleinement valide, et elle peut tre utilis e pour valider pleinement la cl de Francis et valider marginalement la cl de Elena. Pour finir, m me si on a pleinement confiance dans les cl s de Blake, Chlo et Elena, ne suffit pas pour valider la cl de Geoff, car la longueur maximum du chemin pour valider une cl est de trois, alors que la longueur du chemin allant de la cl de Geoff jusqu' 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 avec des cl s publiques. Il vous permet de personnaliser GnuPG pour vos besoins personnels. D'un c t , vous pouvez insister sur de multiples chemins courts allant de votre cl jusqu' une autre cl K pour la valider. D'un autre c 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 devez signer 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 [signatures] +-----------------------------------------------------------------------------+ | confiance | validit | |------------------------------------+----------------------------------------| | marginale | compl te | marginale | compl te | |------------------+-----------------+-------------+--------------------------| | |Dharma | |Blake, Chlo , Dharma, | | | | |Francis | |------------------+-----------------+-------------+--------------------------| |Blake, Dharma | |Francis |Blake, Chlo , Dharma | |------------------+-----------------+-------------+--------------------------| |Chlo , Dharma | |Chlo , |Blake, Dharma | | | |Francis | | |------------------+-----------------+-------------+--------------------------| |Blake, Chlo , | |Elena |Blake, Chlo , Dharma, | |Dharma | | |Francis | |------------------+-----------------+-------------+--------------------------| | |Blake, Chlo , | |Blake, Chlo , Elena, | | |Elena | |Francis | +-----------------------------------------------------------------------------+ ------------------------------------------------------------------------------- Distribution de cl s De mani re id ale, vous devez distribuer vos cl s en les donnant personnellement vos correspondants. Par contre, en pratique, les cl s sont souvent distribu es par email, ou par d'autre moyens lectroniques de communication. La distribution par email est une bonne pratique quand vous avez seulement quelques correspondants, et m me si vous avez de nombreux correspondants, vous pouvez utiliser d'autres moyens comme diffuser votre cl publique sur votre page Web. Ceci n'est pas acceptable si des personnes qui ont besoin de 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 s publiques. Une cl publique re ue par le serveur est soit ajout e la base de donn es du serveur soit fusionn e avec la cl existante si elle est d j pr sente. Quand une requ te de cl arrive au serveur, ce dernier consulte sa base de donn es et renvoie la cl publique s'il la trouve. L'utilisation d'un serveur de cl s est aussi int ressante quand de nombreuses personnes signent fr quemment les cl 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, et la distribuer tous ses correspondants. C'est la responsabilit de Alice et de Blake envers la communaut pour construire une toile de confiance resserr e et ainsi am liorer la s curit de PGP. C'est n anmoins ennuyeux si la signature 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. Les personnes qui veulent mettre jour leur copie de la cl de Alice consultent le serveur de cl s quand ils le souhaitent pour r cup rer la cl mise jour. Alice n'est plus responsable de la distribution, et elle peut r cup rer les signatures sur sa cl publique en interrogeant simplement le serveur de cl s. 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 de cl 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 rer les 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 s certserver.pgp.com et envoie ensuite sa copie de la cl publique de Blake au m me serveur de cl s pour y ajouter toute nouvelle signature qu'elle y aurait ajout e. alice% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC gpg: requesting key BB7576AC from certserver.pgp.com ... gpg: key BB7576AC: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 alice% gpg --keyserver certserver.pgp.com --send-key blake@cyb.org gpg: 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 plus importants se synchronisent entre eux ; il est donc suffisant de s lectionner un serveur de cl s proche de vous sur l'Internet et de l'utiliser r guli rement pour envoyer et recevoir des cl s. ------------------------------------------------------------------------------- Chapitre 4. Utilisation quotidienne de GnuPG GnuPG 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 pas une 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 ou non, 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'il satisfasse vos besoins en mati re de s curit . Il explique aussi comment encourager vos correspondants utiliser GnuPG pour communiquer de mani re s curis e. Finalement, le statut l gal de GnuPG est d crit compte tenu des lois sur l'utilisation du chiffrement travers le monde. ------------------------------------------------------------------------------- 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 pouvez correspondre 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 peuvent vouloir lire les messages que vous chiffrez. La tierce personne peut tre un administrateur syst me peu scrupuleux qui regarde n gligemment vos emails, ou alors un espion industriel qui essaye de r cup rer les secrets 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 en faites pour vous prot ger contre un adversaire d termin . Votre but ultime est de rendre plus co teux le fait de r 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 et en signer d'autres en votre nom. G rer correctement votre toile de confiance emp che qu'un attaquant se fasse passer pour un de vos correspondants et s'interpose entre ce dernier et vous. Finalement, g rer ces diff rents probl mes en fonction de vos besoins en s curit se r sume comment quilibrer la charge de travail suppl mentaire requise pour utiliser GnuPG avec la protection que cela vous apporte. ------------------------------------------------------------------------------- Choisir la taille des cl s Le choix de la taille d'une cl d pend du type de cl . Dans OpenPGP, une paire de cl s comporte souvent de multiples cl s. Elle a au moins une cl principale pour les signatures, et probablement une ou plusieurs sous-cl s additionnelles 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 les techniques 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. A l'oppos , les cl s ElGamal peuvent tre de n'importe quelle taille. tant donn que GnuPG utilise un syst me hybride de chiffrement cl publique, la cl publique est utilis e pour chiffrer la cl de session de 128 bits, et la cl priv e est utilis e pour la d chiffrer. N anmoins la taille de la cl a des r percussions sur la vitesse de chiffrement et de d chiffrement car le co t de ces algorithmes croit de mani re exponentielle avec la taille de la cl . 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 suffisamment grande pour r sister une attaque par la force brute, un espion aura s rement recours d'autres m thodes pour obtenir le texte d chiffr . Par exemple, il peut vous cambrioler chez vous ou au bureau ou vous agresser. Pour cette raison, 1024 bits est la taille de cl recommand e. Si vous avez vraiment besoin d'une cl plus grande, alors vous connaissez s rement d j tout a, et vous devriez plut t consulter un expert en s curit informatique. ------------------------------------------------------------------------------- Prot ger votre cl priv e La protection de votre cl priv e est crucial pour bien utiliser GnuPG. Si quelqu'un obtient votre cl priv e, alors tout ce qui a t chiffr l'intention de cette cl pourra tre d chiffr , et il pourra faire des signatures en votre nom. 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 le seul possesseur de votre cl priv e est catastrophique. Quelle que soit la fa on dont vous utilisez GnuPG, vous devez sauvegarder le certificat de r vocation de votre cl publique et une copie de sauvegarde de votre cl publique sur un support prot g en criture stock dans un lieu s r. Par exemple, vous pouvez les graver sur un CD-ROM et les stocker dans un coffre la banque dans une enveloppe scell e. Vous pouvez aussi les enregistrer sur une disquette et les cacher dans votre maison. Quoi que vous fassiez, ils doivent tre enregistr s sur un support qui doit tre physiquement capable de les m moriser aussi longtemps que vous souhaitez utiliser la cl , et vous devez par cons quent les stocker plus soigneusement que 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 en utilisant un proc d sym trique de chiffrement. C'est la raison pour laquelle vous avez besoin d'un mot de passe pour 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 la cl priv e sur un disque amovible prot g en criture, comme une disquette, et vous devez l'utiliser sur une machine mono-utilisateur d connect e du r seau. C'est peut- tre dur voire carr ment impossible faire pour vous. Par exemple, vous pouvez ne pas poss der votre propre ordinateur et vous devez utiliser un ordinateur au travail ou l' cole, ou cela peut signifier que vous devez d connecter votre ordinateur du r seau chaque fois que vous voulez utiliser GnuPG. Cela ne signifie pas que vous ne devez pas utiliser GnuPG. Cela signifie seulement que vous avez d cid que les donn es que vous prot gez sont suffisamment importantes pour que vous les chiffriez, mais pas assez pour mettre 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 outrepasser le chiffrement utilis pour prot ger cette cl . Au lieu d'utiliser la force brute pour trouver la cl , l'attaquant essayera 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 passe est 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 les mots 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 beaucoup de redondance et peu d'entropie. Vous devez viter le langage naturel si vous le pouvez. Un mot de passe est bon si vous pouvez vous en rappeler et s'il est dur deviner pour les autres. Il doit tre compos de caract res issus de tout l'ensemble des caract res imprimables de votre clavier. Cela inclut les caract res alphab tiques, les nombres, et les caract res sp ciaux comme } ou |. Soyez cr atif et passez un peu de temps consid rer votre mot de passe, un bon choix est tr s important pour assurer votre protection. ------------------------------------------------------------------------------- D finition des dates d'expiration et utilisation des cl s secondaires Par 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 cette raison vous pouvez vouloir que les deux cl s aient des dur es de vie diff rentes. La cl principale est utilis e pour faire les signatures num riques, et elle accumule les signatures des autres qui confirment votre identit . La cl pour le chiffrement est seulement utilis e pour d chiffrer les documents chiffr s qui vous sont envoy s. En g n ral, une signature num rique a une longue dur e de vie, par exemple pour toujours, et vous pouvez aussi ne pas vouloir perdre les signatures sur votre cl que vous avez mis si longtemps accumuler. D'un autre c t , la cl secondaire pour le chiffrement peut changer de mani re p riodique pour plus de s curit , car si une cl de chiffrement est cass e, l'attaquant peut lire tous les documents qui ont t chiffr s destination de cette cl dans le 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 lesquelles vous pouvez choisir une date d'expiration. Premi rement, vous pourriez vouloir que la cl ait une dur e de vie limit e. Par exemple, elle peut tre utilis e pour un v nement particulier comme une campagne politique et elle ne sera d'aucune utilit quand la campagne sera finie. Une autre raison est que si vous perdez le contr le de la cl et que vous n'avez pas de certificat de r vocation, le fait d'avoir une date d'expiration sur la cl principale vous 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 secondaire finira 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 sirent communiquer avec vous doivent r cup rer la cl que vous venez de mettre jour car ils ne pourront plus chiffrer des messages votre attention avec la cl expir e. Cela peut poser probl me suivant la fa on dont vous distribuez votre 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 la cl secondaire prot ge seulement les documents qui seront chiffr s ult rieurement. Pour lire les documents chiffr s avec la nouvelle cl secondaire, l'attaquant devra monter une nouvelle attaque telle que celle qu'il a utilis 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 avoir plusieurs n'apporte aucune s curit suppl mentaire. Il peut bien s r y avoir un nombre quelconque de cl s expir es dans une paire de cl s donn e de mani re ce que les documents chiffr s dans le pass puissent toujours tre d chiffr s, mais un moment donn on a besoin que d'une seule cl secondaire active. ------------------------------------------------------------------------------- G rer votre toile de confiance La gestion de votre toile de confiance, tout comme la protection de votre cl priv e, est un des aspects de l'utilisation de GnuPG. Il est n cessaire de trouver le juste quilibre entre la s curit et la facilit d'utilisation. Si vous utilisez GnuPG pour vous prot ger contre de l'espionnage ou une usurpation d'identit occasionnelle, vous pouvez accorder une confiance relative aux signatures faites par les autres. D'un autre c t , si vous avez faire quelqu'un de d termin envahir votre vie priv e, vous devez moins faire confiance aux signatures des autres, et passer plus de temps v rifier personnellement les signatures. Quels que soient vos besoins en s curit , vous devez toujours tre prudent lorsque vous signez la cl de quelqu'un d'autre. Il est go ste de signer une cl en tant juste assez s r de la validit de la cl pour satisfaire vos propres besoins en mati re de s curit . D'autres, avec des besoins plus stricts, peuvent d pendre de votre signature. S'ils ne peuvent pas avoir confiance en vous, cela affaiblit la toile de confiance et la communication entre les utilisateurs de GnuPG sera plus difficile. Soyez aussi prudent lorsque vous signez des cl s que vous souhaiteriez 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 signez personnellement sera consid r e comme valide, mais part pour les petits groupes, il ne sera pas possible de signer personnellement les cl s de toutes les personnes avec lesquelles vous devez communiquer. C'est la raison pour 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 les options pour d finir la fa on dont GnuPG validera les cl s. Prenons un exemple concret : vous pouvez faire pleinement confiance un groupe d'amis tr s proches que vous savez tre prudents lorsqu'ils valident les cl s, et accorder 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 , vous pouvez r gler ces valeurs respectivement 1 et 3 ou 2 et 3. Si vous tes moins sujet des attaques concernant votre vie priv e ou que vous souhaitez seulement tre raisonnablement s r de la validit des cl s, r glez ces valeurs 1 et 1. En g n ral, des nombres plus grands pour ces options signifient que plus de personnes seront n cessaires pour qu'une conspiration votre gard puisse vous faire croire qu'une cl est valide alors qu'elle n'appartient pas la personne que vous croyez. ------------------------------------------------------------------------------- Construisez votre r seau de confiance Vouloir utiliser soi-m me GnuPG ne suffit pas. Pour pouvoir communiquer de mani re s curis e avec d'autres personnes, 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 GnuPG[8], et il doit y avoir suffisamment de signatures pour 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 de communiquer de mani re s curis e avec tous vos correspondants. Commencez avec un petit nombre de personnes, peut- tre juste vous et un ou deux de vos amis qui veulent utiliser leur droit la protection de leur vie priv e. G n rez vos cl s et signez mutuellement vos cl s publiques. Ceci est votre toile de confiance initiale. En faisant ceci, vous appr cierez la valeur d'une toile de confiance, petite et robuste, et vous serez plus prudent quand 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 avec d'autres personnes qui utilisent GnuPG. Toutefois, ceci peut tre g nant pour deux raisons : (1) on ne sait pas toujours quand quelqu'un utilise ou veut utiliser GnuPG et (2) si vous connaissez quelqu'un qui l'utilise, vous aurez encore des probl mes pour valider sa cl . La premi re raison cela est que les gens ne font pas toujours de la publicit pour dire qu'ils utilisent GnuPG. Pour changer ce comportement, il faut montrer l'exemple et pr venir que vous utilisez GnuPG. Il y a au moins trois fa ons de le faire : vous pouvez signer les messages que vous envoyez aux autres ou que vous postez publiquement, vous pouvez diffuser votre cl publique sur votre page web ou si vous avez mis votre cl sur un serveur de cl s, vous pouvez ajouter l'identifiant de votre cl dans votre signature d'email. Si vous promouvez votre cl , vous rendez la chose plus normale accepter pour les autres. De plus, il sera plus facile pour les autres de commencer communiquer de mani re s curis e avec vous car 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 la cl en question jusqu' la v tre. Pour avoir une chance de trouver une cha ne, vous devez prendre l'initiative et faire signer votre cl par d'autres personnes ne faisant pas partie de votre toile de confiance initiale. Pour accomplir ceci, participez des "key signing parties". Si vous allez une conf rence, regardez l'avance s'il y a une key signing party de pr vue, et s'il n'y en a pas, proposez d'en organiser une. Vous pouvez aussi tre plus passif et avoir votre empreinte de cl avec vous pour des changes de cl s plus impromptus. Dans une telle situation, la personne qui vous donnez 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 signer la cl des autres. La puissance de GnuPG r side dans le fait qu'il est suffisamment flexible pour s'adapter vos besoins en s curit quels qu'ils soient. Toutefois, en r alit , vous devrez prendre l'initiative si vous voulez agrandir votre toile de confiance et utiliser GnuPG pour effectuer une partie satisfaisante de votre communication. ------------------------------------------------------------------------------- Utiliser GnuPG l galement Le statut l gal du chiffrement de donn es varie d'un pays l'autre, et les lois concernant le chiffrement voluent rapidement. Bert-Japp Koops tient jour le Crypto Law Survey auquel vous pouvez vous r f rer si vous souhaitez conna tre le statut l gal du chiffrement dans votre pays. ------------------------------------------------------------------------------- Chapitre 5. Divers Ce chapitre traite de divers sujets qui ne pouvaient pas tre class s ailleurs dans le manuel. Au fur et mesure que des sujets sont ajout s, ils pourront tre rassembl s dans des chapitres. Si vous souhaitez voir trait un sujet en particulier, sugg rez-le. Mieux encore, portez-vous volontaire pour crire un premier brouillon concernant ce sujet! ------------------------------------------------------------------------------- crire des interfaces utilisateur Alma Whitten et Doug Tygar ont r alis une tude sur l'interface utilisateur du PGP 5.0 de NAI et sont arriv s la conclusion que pour un utilisateur d butant, PGP peut para tre confus et frustrant. Dans leur tude sur des sujets humains, seuls quatre des douze sujets ont r ussi envoyer des mails chiffr 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 tes familier avec la fa on dont fonctionne le chiffrement cl publique et le mod le de gestion des cl s de la toile de confiance 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 des commentaires pour chacun des sujets du test, et ces d tails sont tr s instructifs. Par exemple, il appara t qu'une bonne partie des sujets croyaient qu'un message envoyer devait tre chiffr avec leur propre cl publique. En y r fl chissant, vous conviendrez que c'est une erreur facile commettre. En g n ral, les utilisateurs d butants ont des difficult s pour comprendre les diff rents r les des cl s publiques et priv es dans GnuPG. En tant que concepteur 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 ration des cl s, l'int rieur desquelles des tapes annexes comme la g n ration du certificat de r vocation et la r alisation d'une copie de sauvegarde qui sont essentielles pour utiliser GnuPG correctement. Le rapport comporte aussi les commentaires suivants : * La s curit est un objectif secondaire. Les utilisateurs veulent envoyer des mails, surfer, etc. Il ne faut pas s'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. Les utilisateurs doivent tre guid s pour consid rer tous les aspects de leur s curit , et surtout ne doivent pas tres abandonn s eux-m mes pour proc der des explorations al atoires comme ils pourraient le faire avec un traitement de texte ou un tableur. * Utilisez les m mes termes pour d crire les m mes choses. Ne pas utiliser alternativement des synonymes comme ``chiffrer'' et ``encoder''. * Pour des utilisateurs inexp riment s, simplifiez les affichages. Trop d'informations peuvent masquer l'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 comment les obtenir et les distribuer. Concevoir une interface utilisateur efficace pour la gestion des cl s est encore plus difficile. La toile de confiance de OpenPGP est malheureusement plut t obscure. Par exemple, la sp cification impose trois niveaux de confiance pour un utilisateur : aucune, marginale et compl te. La confiance effectivement accord e par l'utilisateur doit correspondre un de ces trois niveaux. L'algorithme de validation des cl s est difficile 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 tre chang , vous allez devoir faire de votre mieux pour concevoir une interface utilisateur qui puisse le clarifier pour l'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 les emp cher de commettre des erreurs qui pourraient leur co ter cher. De telles erreurs pourraient tre : effacer accidentellement leur cl priv e, publier ou r voquer accidentellement une cl , oublier leur mot de passe, ne pas sauvegarder leurs trousseaux. ------------------------------------------------------------------------------- Annexe A. GNU Free Documentation License Version 1.1, March 2000 Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. ------------------------------------------------------------------------------- 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit 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 free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: 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 subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. ------------------------------------------------------------------------------- 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can 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, either copied 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 exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship 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 Invariant Sections, 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, in the 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 whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque". 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 HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes 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 any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. ------------------------------------------------------------------------------- 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use 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 of copies 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 QUANTITY If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires 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 and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be 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 many as 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 a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or 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 large number of copies, to give them a chance to provide you with an updated version of the Document. ------------------------------------------------------------------------------- 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses 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 of previous versions (which should, if there were any, be listed in the History section of the Document). You may 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 the modifications 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 the Modified 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 the Document'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, new authors, 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 as given 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 the Document, 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 was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers 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 and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. 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 Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit 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 for publicity for or to assert or imply endorsement of any Modified Version. ------------------------------------------------------------------------------- 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced 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 original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles 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, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements." ------------------------------------------------------------------------------- 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all 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 other respects regarding verbatim copying of that document. ------------------------------------------------------------------------------- 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, 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 is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. ------------------------------------------------------------------------------- 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. ------------------------------------------------------------------------------- 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. ------------------------------------------------------------------------------- 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new 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 particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. ------------------------------------------------------------------------------- How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following 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 the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License". 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 in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. Notes [1] 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 de configuration. [4] 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. [5] ndt : pourquoi pas votre surnom. [6] ndt : en anglais Web Of Trust [7] GnuPG utilise le mot ``trust'' pour signifier la confiance dans le propri taire et la confiance dans la cl . Ceci peut tre la source de confusion. Parfois la confiance dans le propri taire est appel e owner-trust pour marquer la diff rence avec la confiance dans la cl . Dans ce manuel, ``confiance'' est utilis pour signifier la confiance dans le propri taire de la cl , et ``validit '' est utilis pour signifier le fait que la cl appartient vraiment la personne associ e avec l'identifiant d'utilisateur de la cl . [8] 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.