title: Les problèmes de PGP
url: http://blog.notmyidea.org/les-problemes-de-pgp.html
hash_url: c6671c1b2ff653b81dbae9420b10f03c

<blockquote class="epigraph">
<p>Flip a bit in the communication between sender and recipient and they will
experience decryption or verification errors. How high are the chances they
will start to exchange the data in the clear rather than trying to hunt down
the man in the middle?</p>
<p class="attribution">&mdash;<a class="reference external" href="http://secushare.org/PGP">http://secushare.org/PGP</a></p>
</blockquote>
<p>Une fois passé l'euphorie du &quot;il faut utiliser PGP pour l'ensemble de nos
communications&quot;, j'ai réalisé lors de discussions que PGP avait plusieurs
problèmes, parmi ceux-ci:</p>
<ul class="simple">
<li>Les <em>meta données</em> (y compris le champ &quot;sujet&quot; de la conversation) sont quand
même échangées en clair (il est possible de savoir qu'un message à été échangé
entre telle et telle personne, a telle date);</li>
<li>PGP se base sur un protocole de communication qui est lui non chiffré, et il
est donc facile de soit se tromper, soit dégrader le mode de conversation vers
une méthode non chiffrée;</li>
<li>Il est facile de connaître votre réseau social avec PGP, puisque tout le
principe est de signer les clés des personnes dont vous validez l'identité;</li>
<li>En cas de fuite de votre clé privée, tous les messages que vous avez chiffrés
avec elle sont compromis. On dit que PGP ne fournit pas de <em>forward secrecy</em>;</li>
<li>La découverte de la clé de pairs se passe souvent <em>en clair</em>, sans utiliser une
connexion &quot;sécurisée&quot; (HTTPS). Tout le monde peut donc voir ces échanges et
savoir de qui vous cherchez la clé;</li>
<li>Les discussions de groupes sont très difficiles: il faut chiffrer pour chacun
des destinataires (ou que ceux-ci partagent une paire de clés).</li>
</ul>
<p>Je suis en train de creuser à propos les alternatives à PGP, par exemple <a class="reference external" href="https://pond.imperialviolet.org/">Pond</a>, qui lui ne construit pas par dessus un
standard déjà établi, et donc n'hérite pas de ses défauts (mais pas non plus de
son réseau déjà établi).</p>
<p>En attendant, quelques bonnes pratiques sur PGP ;)</p>
<div class="section" id="bonnes-pratiques">
<h2>Bonnes pratiques</h2>
<p>Il est en fait assez facile d'utiliser PGP de travers. Riseup à fait <a class="reference external" href="https://help.riseup.net/en/security/message-security/openpgp/best-practices">un
excellent guide</a>
qui explique comment configurer son installation correctement.</p>
<ul class="simple">
<li>J'en ai déjà parlé, mais il faut absolument choisir des phrases de passes
suffisamment longues. Pas facile de les retenir, mais indispensable. Vous
pouvez aussi avoir un document chiffré avec une clé que vous ne mettez jamais
en ligne, qui contiens ces phrases de passe, au cas ou vous les oubliez.</li>
<li>Générez des clés RSA de 4096 bits, en utilisant sha512;</li>
<li>Il faut utiliser une date d'expiration de nos clés suffisamment proche (2
ans). Il est possible de repousser cette date si nécessaire, par la suite.</li>
</ul>
<p>Parmi les choses les plus frappantes que j'ai rencontrées:</p>
<ul class="simple">
<li>Utiliser le <em>flag</em> <cite>–hidden-recipient</cite> avec PGP pour ne pas dévoiler qui est
le destinataire du message;</li>
<li>Ne pas envoyer les messages de brouillons sur votre serveur, ils le seraient
en clair !;</li>
<li>Utilisez HPKS pour communiquer avec les serveurs de clés, sinon tout le
trafic est en clair.</li>
</ul>
<p>Le <a class="reference external" href="https://bitmask.net/">projet Bitmask</a> vise lui à rendre les outils de
chiffrement d'échanges de messages et de VPN simples à utiliser, encore quelque
chose à regarder.</p>
<p>Enfin bref, y'a du taf.</p>