/usr/share/doc/gnupg-doc/GNU_Privacy_Handbook/fr/html/c496.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Utilisation quotidienne de GnuPG</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Le manuel de GNU Privacy Guard"
HREF="book1.htm"><LINK
REL="PREVIOUS"
TITLE="Distribution de clés"
HREF="x473.htm"><LINK
REL="NEXT"
TITLE="Construisez votre réseau de confiance"
HREF="x562.htm"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Le manuel de GNU Privacy Guard</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x473.htm"
ACCESSKEY="P"
>Précédent</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x562.htm"
ACCESSKEY="N"
>Suivant</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="WISE"
></A
>Chapitre 4. Utilisation quotidienne de GnuPG</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table des matières</B
></DT
><DT
><A
HREF="c496.htm#AEN502"
>Définir vos besoins en matière de sécurité</A
></DT
><DT
><A
HREF="x562.htm"
>Construisez votre réseau de confiance</A
></DT
><DT
><A
HREF="x572.htm"
>Utiliser GnuPG légalement</A
></DT
></DL
></DIV
><P
>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.</P
><P
>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.</P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN502"
>Définir vos besoins en matière de sécurité</A
></H1
><P
>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.</P
><P
>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.</P
><P
>Adapter l'utilisation de GnuPG à vos besoins se résume à quatre
problèmes :
<P
></P
><UL
COMPACT="COMPACT"
><LI
><P
>choisir la taille de votre paire de clés,</P
></LI
><LI
><P
>protéger votre clé privée,</P
></LI
><LI
><P
>définir les dates d'expiration et l'utilisation des clés secondaires,</P
></LI
><LI
><P
>gérer votre toile de confiance.</P
></LI
></UL
>

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.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN516"
>Choisir la taille des clés</A
></H2
><P
>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.</P
><P
>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.</P
><P
>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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN521"
>Protéger votre clé privée</A
></H2
><P
>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.</P
><P
>Quelle que soit la façon dont vous utilisez GnuPG, vous devez
sauvegarder le <A
HREF="c16.htm#REVOCATION"
>certificat de
révocation</A
> 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.</P
><P
>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.</P
><P
>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.</P
><P
>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.</P
><P
>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.</P
><P
>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.</P
><P
>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 <TT
CLASS="LITERAL"
>}</TT
> ou
<TT
CLASS="LITERAL"
>|</TT
>.
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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN534"
>Définition des dates d'expiration et utilisation des clés secondaires</A
></H2
><P
>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.</P
><P
>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.</P
><P
>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.</P
><P
>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.</P
><P
>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.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN541"
>Gérer votre toile de confiance</A
></H2
><P
>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.</P
><P
>Quels que soient vos besoins en sécurité, vous devez
<I
CLASS="EMPHASIS"
>toujours être prudent</I
> 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.</P
><P
>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
<CODE
CLASS="OPTION"
>--marginals-needed</CODE
>
et <CODE
CLASS="OPTION"
>--completes-needed</CODE
>.
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.</P
><P
>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 <CODE
CLASS="OPTION"
>--completes-needed</CODE
>
à <TT
CLASS="LITERAL"
>1</TT
> et <CODE
CLASS="OPTION"
>--marginals-needed</CODE
> à
<TT
CLASS="LITERAL"
>2</TT
>.
Si vous êtes plus concerné par votre sécurité, vous pouvez régler ces
valeurs respectivement à
<TT
CLASS="LITERAL"
>1</TT
> et <TT
CLASS="LITERAL"
>3</TT
> ou à <TT
CLASS="LITERAL"
>2</TT
>
et <TT
CLASS="LITERAL"
>3</TT
>.
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 à <TT
CLASS="LITERAL"
>1</TT
> et
<TT
CLASS="LITERAL"
>1</TT
>.
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.</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x473.htm"
ACCESSKEY="P"
>Précédent</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
ACCESSKEY="H"
>Sommaire</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x562.htm"
ACCESSKEY="N"
>Suivant</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Distribution de clés</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Construisez votre réseau de confiance</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
gnupg-doc 2003.04.06+dak1-1ubuntu1 / usr / share / doc / gnupg-doc / GNU_Privacy_Handbook / fr / html / c496.htm
