Différences

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

--- cryptographie:gnupg [2017/12/03 15:43] – Update link 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 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