Différences

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

--- cryptographie:gnupg [2017/09/08 17:22] – [Le fichier gpg.conf] no-try-dns-srv in now deprecated 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 176: / Ligne 169: @@
 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 302: / 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 508: / 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 569: / 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