Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cryptographie:gnupg [2016/11/20 11:10] – [Utilisation de GNU Privacy Guard] ajout d'un lien vers dirmngr d2air
+++ cryptographie:gnupg [2019/11/10 14:56] (Version actuelle) – [RNG-Tools] d2air
@@ Ligne 8: / Ligne 8: @@
 sudo apt-get update && sudo apt-get install rng-tools
 </code>
-Pour configuer ''rng-tools'' il faut éditer le fichier ''/etc/default/rng-tools'' pour ajouter cette ligne :
+Pour configuer ''rng-tools'' il faut éditer le fichier ''/etc/default/rng-tools'', mais c'est normalement inutile celui-ci pouvant reconnaître seul les sources d'entropie. Il faudra surtout éviter de le configurer avec ''/dev/urandom'' comme source.
-<file sh rng-tools>
-HRNGDEVICE=/dev/urandom
-</file>
-Et ensuite il faudra relancer ce service avec la commande :
-<code>
-sudo service rng-tools restart
-</code>
 ===== Configuration de GNUPG =====
 Il existe un très bon guide sur [[https://help.riseup.net/fr/security/message-security/openpgp/best-practices|help.riseup.net]] et une mise en application du fichier de configuration sur le GIT [[https://github.com/ioerror/duraconf/|duraconf]]
@@ Ligne 35: / Ligne 28: @@
 keyserver hkps://hkps.pool.sks-keyservers.net
 keyserver-options ca-cert-file=/etc/ssl/certs/sks-keyservers.netCA.pem.pem
+</file>
+Pour les versions supérieures à la 2.1 de GnuPG, il faut enlever l'option devenue obsolète ''ca-cert-file'' du fichier ''gpg.conf'' et ajouter sa remplaçante ''hkp-cacert'' en bas du fichier ''dirmngr.conf''.
+<file sh dirmngr.conf>
+hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem.pem
 </file>
 Avec cette configuration les interactions avec le serveur de clés seront chiffrées avec ''hkps'', qui masquera notre réseau de relations sociales pour éviter qu’il soit divulgué à quiconque intercepterait le trafic réseau. Par exemple, si vous faites ''gpg --refresh-keys'' sur un serveur de clés qui ne supporte que ''hkp'', quelqu’un surveillant le trafic pourrait voir toutes les clés que nous possédons dans notre trousseau en observant les demandes de mises à jour envoyées pour chacune d’entre elles. C’est là une information plutôt intéressante!
@@ Ligne 122: / Ligne 119: @@
 # Provide a certificate store to override the system default
 # Get this from https://sks-keyservers.net/sks-keyservers.netCA.pem
+# Comment this option for GnuPG 2.1 and higher versions
 keyserver-options ca-cert-file=/etc/ssl/certs/sks-keyservers.netCA.pem.pem
@@ Ligne 132: / Ligne 130: @@
 # Don't leak DNS, see https://trac.torproject.org/projects/tor/ticket/2846
-keyserver-options no-try-dns-srv
+# keyserver-options no-try-dns-srv (no-try-dns-srv in now deprecated)
 # When using --refresh-keys, if the key in question has a preferred keyserver
@@ Ligne 162: / Ligne 160: @@
 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
 </file>
+==== Le fichier dirmngr.conf ====
+Pour les versions supérieures à la 2.1 de GnuPG, il faut ajouter en bas du fichier ''dirmngr.conf'' la ligne suivante :
+<file sh dirmngr.conf>
+hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem.pem
+</file>
 ===== Configuration de la clef =====
 ==== Clef primaire robuste ====
 Il est recommandé de générer une clé RSA de 4096 bits avec l’algorithme de hachage SHA-512.
 ==== Transition d'une ancienne clef ====
-En cas transition, une méthode est de rédiger un [[https://we.riseup.net/assets/176898/key%20transition|communiqué de transition]] signé par les deux clés, puis en informer les gens. [[http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/|Cette page]] détaille le processus à suivre pour générer une telle clé en s’assurant d’utiliser le bon algorithme de hachage (ça peut être compliqué avec des versions de GnuPG plus anciennes que la 1.4.10).
+En cas transition, une méthode est de rédiger un [[https://riseup.net/fr/security/message-security/openpgp/key-transition|communiqué de transition]] signé par les deux clés, puis en informer les gens. [[http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/|Cette page]] détaille le processus à suivre pour générer une telle clé en s’assurant d’utiliser le bon algorithme de hachage (ça peut être compliqué avec des versions de GnuPG plus anciennes que la 1.4.10).
 ==== Délai d'expiration ====
 Mettre une date d’expiration sur sa clé est une bonne chose. Pourquoi? Parce que vous pouvez toujours étendre votre date d’expiration, même une fois qu’elle est passée! Cette expiration est plutôt une sorte de valve de sûreté ou un ''dispositif de l’homme mort'' qui se déclenchera automatiquement à un certain moment. Si vous avez accès à la clé privée, vous pouvez le désamorcer. L’idée est de configurer un mécanisme qui désactivera votre clé au cas où vous n’y accéderiez plus (et ne disposez pas d’un certificat de révocation).
@@ Ligne 293: / Ligne 295: @@
 Pour voir les clefs privées associées, il faut utiliser la commande ''toggle''.
-Avec la commande de génération de clés, GnuPG ne crée pas une paire mais deux. La première est utilisable pour signer d'autres clés ainsi que des documents mais c'est une sous-clé (subkey ou clé subordonnée) qui est utiliser pour chiffrer.
+Avec la commande de génération de clés, GnuPG ne crée pas une paire mais deux. La première est utilisable pour signer d'autres clés ainsi que des documents mais c'est une sous-clé (subkey ou clé subordonnée) qui est utilisée pour chiffrer.
-Pourquoi? Pour des raisons de sécurité mais surtout de praticité, tout le fonctionnement du réseau de confiance repose sur la signature des clefs publiques des utilisateurs. Si la clé de chiffrement est corrompue (par exemple un attaquant souhaitant lire nos messages et qui réussit) elle pourra être révoquer et une nouvelle pourra être créer, cette nouvelle clé sera rattachée à la clé maîtresse qui ne sera pas corrompue (enfin normalement) et il ne sera pas nécessaire de reconstruire les signatures sur la clé publique détruisant par la même le réseau de confiance.
+Pourquoi? Pour des raisons de sécurité mais surtout de praticité, tout le fonctionnement du réseau de confiance repose sur la signature des clefs publiques des utilisateurs. Si la clé de chiffrement est corrompue (par exemple un attaquant souhaitant lire nos messages et qui réussit) elle pourra être révoquée et une nouvelle pourra être créer, cette nouvelle clé sera rattachée à la clé maîtresse qui ne sera pas corrompue (enfin normalement) et il ne sera pas nécessaire de reconstruire les signatures sur la clé publique détruisant par la même le réseau de confiance.
 GnuPG fait cela par défaut avec les options 1 et 2 du processus de génération de clefs de la commande ''gpg2 --gen-key''. Les options 3 et 4 de ce processus permettent de créer une seule et unique paire maîtresse.
@@ Ligne 499: / Ligne 501: @@
 <code>
 gpg2 --list-secret-keys
-/home/d2air/.gnupg/secring.gpg
+/home/john/.gnupg/secring.gpg
 ------------------------------
 sec#  4096R/0xA0B00000000000FF 2015-11-01 [expire : 2017-10-31]
@@ Ligne 560: / Ligne 562: @@
 gpg2 --home=/media/veracrypt1 --armor --export 0xA0B00000000000FF > maj-clepublique.asc
 </code>
-Attention cette commande mettra à jour que la partie publique des clés. Il faudra faire la même opération pour les clés privées mais il existe un problème du fusion des sous-clés, il n'existe pas de mise à jour des sous-clés secrètes. Pour contrer ce problème il faut effacer toutes les clés privées du répertoire courant (celui sans la clé privée maîtresse) puis exporter les sous-clés secrètes du répertoire alternatif pour les importer dans le répertoire courant.
+Attention cette commande mettra à jour que la partie publique des clés. Il faudra faire la même opération pour les clés privées mais il existe un **problème de fusion des sous-clés**, il n'existe pas de mise à jour des sous-clés secrètes. Pour contrer ce problème il faut effacer toutes les clés privées du répertoire courant (celui sans la clé privée maîtresse) puis exporter les sous-clés secrètes du répertoire alternatif pour les importer dans le répertoire courant.
 <code>
 gpg2 --delete-secret-keys 0xA0B00000000000FF