GPG : comment créer une paire de clefs presque parfaite

GPG : comment créer une paire de clefs presque parfaite

Paré pour votre prochaine chiffrofête

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

28/01/2017 18 minutes
70

GPG : comment créer une paire de clefs presque parfaite

Aujourd'hui, c'est la journée européenne de la protection des données. Nous avons donc décidé de vous occuper avec un nouveau guide qui prend place au sein de notre dossier dédié au chiffrement. Celui-ci vous permettra de créer une paire de clefs GnuPG plus robuste et utilisable au quotidien.

Récemment, nous avons débuté un dossier sur le chiffrement. Tout d'abord en vous permettant d'expliquer au mieux cette notion à vos proches, mais aussi en revenant plus en détail sur l'histoire de GnuPG (GPG) et sur la façon de créer votre première paire de clefs afin de chiffrer des fichiers.

En cette journée européenne de la protection des données, nous avons décidé de passer à l'étape suivante : vous permettre de créer une paire de clefs presque parfaite. Pourquoi presque ? Parce que tout est toujours perfectible, surtout lorsqu'il est question de sécurité. Nous n'hésiterons d'ailleurs pas à mettre à jour ce guide avec de nouvelles astuces si cela est nécessaire ou si certaines sont partagées au sein de nos commentaires.

La seconde question à se poser est « Pourquoi un tel guide est nécessaire ? ». La raison est simple : tout pratique et simple à installer que soit GPG, ses paramètres par défaut sont loin d'être optimaux, comme nous avons déjà eu l'occasion de l'évoquer. Certes, cela a tendance à évoluer dans le bon sens, mais il y a encore du chemin à parcourir.

Nous avons donc décidé de vous détailler quelques étapes à suivre pour mieux comprendre et générer une paire de clefs plus robuste de manière simple. Cela devrait aussi vous permettre de vous simplifier un peu la vie au quotidien.

Renforcer l'environnement depuis lequel la clef est générée

La première chose à savoir est qu'il est toujours préférable de générer votre paire de clefs sur une machine de confiance. Dans l'idéal, cela doit donc être fait sur une machine disposant d'un système d'exploitation open source, qui n'est pas reliée à Internet (Tails fait en général très bien l'affaire).

Ensuite, il faut commencer par renforcer les paramètres par défaut de GnuPG. Plusieurs méthodes existent pour cela, mais le plus simple est d'éditer le fichier de configuration. Celui-ci se trouve à l'endroit suivant :

  • Linux et macOS : ~/.gnupg/gpg.conf
  • Windows : C:\Users\[nom de l'utilisateur]\AppData\Roaming\gnupg\gpg.conf

Si vous êtes sous Windows, nous avons créé un petit utilitaire vous permettant d'ouvrir ce fichier afin de le modifier sans avoir à fouiller dans des dossiers cachés. Il est disponible par ici.

Par défaut, la plupart des lignes seront commentées, de manière à être sans aucune action. Il faut donc le compléter afin de préciser certains paramètres utiles qui viendront renforcer différents éléments du fonctionnement de GPG et limiter l'utilisation de certains algorithmes. 

Pour établir la liste définitive, nous nous sommes notamment fondés sur les conseils d'Aeris22 et les best practices de Riseup.net. Les détails sur les paramètres S2K peuvent être trouvés dans la RFC 4880 à la section 3.7.

Il suffit donc d'ajouter ces lignes à la fin de votre fichier ou de remplacer les valeurs, si jamais il avait déjà été modifié :

# Limite les informations diffusées
no-emit-version
no-comments
export-options export-minimal

# Permet d'afficher le format long de l'ID des clefs et leurs empreintes
keyid-format 0xlong
with-fingerprint

# Affiche la validité des clefs
list-options show-uid-validity
verify-options show-uid-validity

# Limite les algorithmes utilisés
personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed

cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB

disable-cipher-algo 3DES
weak-digest SHA1

# Paramètres S2K (String-to-Key) de la phrase de passe des clefs
# Le paramètre s2k-count peut être réduit sur les machines peu puissantes
s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

Notez que la ligne weak-digest SHA1 peut poser problème avec d'anciennes versions de GPG. Si tel est le cas vous pouvez la commenter (en rajoutant un # en début de ligne).

Vous pouvez aussi ajouter le paramètre throw-keyids qui permet de cacher pour quel destinataire est chiffré un message, ce qui apporte une couche de sécurité complémentaire. Mais cela peut parfois complexifier le déchiffrement, puisque la machine du destinataire devra tester les différentes clefs privée dont elle dispose avant de trouver la bonne, comme l'avait expliqué Stéphane Bortzmeyer dans l'un de ses articles.

L'importance de disposer de sous-clefs

Une fois le fichier enregistré, passons à la création de notre paire de clefs. Nous utiliserons à nouveau la version 2.1 de GPG pour notre démonstration (gpg2 sous Linux, voir la procédure d'installation). Comme nous l'avions évoqué dans notre précédent guide, il est possible de disposer de sous-clefs en complément de la clef primaire. Chacune pouvant se voir attribuer des tâches spécifiques : 

  • Signature (S)
  • Certification (C)
  • Chiffrement (E)
  • Authentification (A)

La différence, c'est que ces sous-clefs sont liées à la clef primaire mais peuvent être révoquées de manière indépendante (voir ici pour la méthode). Utile pour ceux qui veulent changer souvent de clef de chiffrement (pour reproduire une sorte de Perfect Forward Secrecy).

Mais surtout, si l'une d'entre elles venait à être découverte ou perdue, vous pouvez la révoquer et en générer une nouvelle depuis votre clef primaire. Cela n'empêchera pas celui qui l'a trouvé de l'utiliser et de chiffre/déchiffrer vos documents et emails antérieurs s'il dispose de la phrase de passe associée, mais cela vous permettra de repartir facilement sur des bases saines.

Alors que si vous perdez l'accès à votre clef primaire, tout est perdu puisque vous devrez alors générer une nouvelle clef complète. De plus, un attaquant pourrait éventuellement générer de nouvelles clefs secondaires et se faire passer pour vous s'il dispose de votre phrase de passe. Il faut donc la protéger à tout prix.

Mais il est nécessaire de disposer au quotidien de quoi chiffrer et signer des documents ou des emails, même sur des machines plus accessibles à des tiers telles que des ordinateurs portables. Nous allons donc attribuer ces fonctionnalités à des sous-clefs que l'on pourra utiliser simplement.

Nous garderons la certification pour la clef primaire que l'on gardera bien au chaud sur une machine de confiance (et pourquoi pas hors-ligne), ou un autre système de stockage (clef USB mise en sécurité, format papier, etc). Une stratégie notamment détaillée par l'équipe de Debian, mais aussi recommandée par Riseup ou le guide d'Alex Cabal.

Création de la clef de base

Comme nous l'avons déjà vu, chaque méthode de création d'une paire de clefs peut aboutir à un résultat différent. Nous allons donc utiliser la ligne de commande qui a l'avantage d'être identique quel que soit le système. Le plus souvent, il est conseillé de créer une clef avec la méthode de base, ce qui a pour effet de mettre en place une clef primaire gérant la signature et la certification, ainsi qu'une sous-clef pour le chiffrement. On viendra ensuite modifier sa composition.

Dans notre cas, nous allons opter pour une méthode plus directe en limitant dès le départ les capacités de la clef primaire à la fonction de certification (C). Pour rappel, c'est ce qui permet d'indiquer le niveau de confiance lors de la signature de la clef d'un tiers dans le cadre du Web of trust. Une fonctionnalité importante qu'il faut préserver, mais qu'il n'est pas nécessaire d'utiliser au quotidien.

Pour cela nous pouvons utiliser la création en mode expert via la commande gpg --full-gen-key --expert afin de pouvoir sélectionner dès le départ les actions possibles avec la clef, il existe aussi une méthode plus rapide depuis GPG 2.1 que nous détaillerons un peu plus bas.

Comme lors de nos démonstrations précédentes, nous allons opter pour du RSA de 4096 bits (choix 8) valable pour une durée d'un an (1y). Bien entendu, vous pouvez opter pour une clef utilisant la cryptographie sur les courbes elliptiques (ECC) si vous le préférez, ou même tester la création d'une clef RSA jusqu'à 8 192 bits avec l'option --enable-large-rsa. Attention, dans ce dernier cas, votre clef pourrait ne pas être supportée par certains systèmes et applications.

gpg --full-gen-key --expert

gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Sélectionnez le type de clef désiré :
(1) RSA et RSA (par défaut)
(2) DSA et Elgamal
(3) DSA (signature seule)
(4) RSA (signature seule)
(7) DSA (indiquez vous-même les capacités)
(8) RSA (indiquez vous-même les capacités)
(9) ECC et ECC
(10) ECC (signature seule)
(11) ECC (indiquez vous-même les capacités)
Quel est votre choix ? 8

Actions possibles pour une clef RSA : Signer Certifier Chiffrer Authentifier
Actions actuellement permises : Signer Certifier Chiffrer
(S) Inverser la capacité de signature
(C) Inverser la capacité de chiffrement
(A) Inverser la capacité d'authentification
(Q) Terminé
Quel est votre choix ? s

Actions possibles pour une clef RSA : Signer Certifier Chiffrer Authentifier
Actions actuellement permises : Certifier Chiffrer
(S) Inverser la capacité de signature
(C) Inverser la capacité de chiffrement
(A) Inverser la capacité d'authentification
(Q) Terminé
Quel est votre choix ? c

Actions possibles pour une clef RSA : Signer Certifier Chiffrer Authentifier
Actions actuellement permises : Certifier
(S) Inverser la capacité de signature
(C) Inverser la capacité de chiffrement
(A) Inverser la capacité d'authentification
(Q) Terminé
Quel est votre choix ? q

les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits

Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
0 = la clef n'expire pas
<n> = la clef expire dans n jours
<n>w = la clef expire dans n semaines
<n>m = la clef expire dans n mois
<n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 1y

La clef expire le 01/28/18 17:17:10 Paris, Madrid
Est-ce correct ? (o/N) o

GnuPG doit construire une identité pour identifier la clef.
Nom réel : Jean Deauh
Adresse électronique : [email protected]
Commentaire :

Vous avez sélectionné cette identité :
« Jean Deauh <[email protected]> »
Changer le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? o

De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

gpg: clef 0x1C141B1DE773D6CA marquée de confiance ultime.
gpg: revocation certificate stored as ''
les clefs publique et secrète ont été créées et signées.
pub rsa4096/0x1C141B1DE773D6CA 2017-01-28 [C] [expire : 2018-01-28]
Empreinte de la clef = E6D9 DD35 E023 3198 EFAF 68F5 1C14 1B1D E773 D6CA
uid Jean Deauh <[email protected]>

Notez que vous avez aussi la possibilité depuis les versions récentes de GPG d'utiliser une ligne de commandes rapide pour effectuer une telle action : 

gpg --quick-gen-key 'Jean Deauh <[email protected]>' rsa4096 cert 1y

Ajout des sous-clefs de chiffrement et de signature

Nous avons donc obtenu ce que nous voulions, une paire de clef avec une clef primaire qui ne dispose que d'une fonction de certification. Il faut maintenant lui rajouter des sous-clefs afin de disposer de quoi chiffrer et signer des documents. 

Pour cela il faut commencer à éditer la clef (en tapant l'ID/empreinte de celle-ci, ou l'adresse email associée par exemple) :

gpg --edit-key <[email protected]>

gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

La clef secrète est disponible.

sec rsa4096/0x1C141B1DE773D6CA
créé : 2017-01-28 expire : 2018-01-28 utilisation : C
confiance : ultime validité : ultime
[ ultime ] (1). Jean Deauh <[email protected]>

Ensuite, il faut demander l'ajout de sous clefs de signature, puis une autre pour le chiffrement avec la commande addkey. Celles-ci peuvent utiliser différents algorithmes mais aussi disposer de leur propre date d'expiration. Nous avons là encore opté pour du RSA 4096 bits avec une durée de vie d'un an.

gpg> addkey

Sélectionnez le type de clef désiré :
(3) DSA (signature seule)
(4) RSA (signature seule)
(5) Elgamal (chiffrement seul)
(6) RSA (chiffrement seul)
Quel est votre choix ? 4
les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
0 = la clef n'expire pas
<n> = la clef expire dans n jours
<n>w = la clef expire dans n semaines
<n>m = la clef expire dans n mois
<n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 1y
La clef expire le 01/28/18 17:36:16 Paris, Madrid
Est-ce correct ? (o/N) o
Faut-il vraiment la créer ? (o/N) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

sec rsa4096/0x1C141B1DE773D6CA
créé : 2017-01-28 expire : 2018-01-28 utilisation : C
confiance : ultime validité : ultime
ssb rsa4096/0x7B0E97F0E71AF6AA
créé : 2017-01-28 expire : 2018-01-28 utilisation : S
[ ultime ] (1). Jean Deauh <[email protected]>

gpg> addkey
Sélectionnez le type de clef désiré :
(3) DSA (signature seule)
(4) RSA (signature seule)
(5) Elgamal (chiffrement seul)
(6) RSA (chiffrement seul)
Quel est votre choix ? 6
les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
0 = la clef n'expire pas
<n> = la clef expire dans n jours
<n>w = la clef expire dans n semaines
<n>m = la clef expire dans n mois
<n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 1y
La clef expire le 01/28/18 17:37:42 Paris, Madrid
Est-ce correct ? (o/N) o
Faut-il vraiment la créer ? (o/N) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

sec rsa4096/0x1C141B1DE773D6CA
créé : 2017-01-28 expire : 2018-01-28 utilisation : C
confiance : ultime validité : ultime
ssb rsa4096/0x7B0E97F0E71AF6AA
créé : 2017-01-28 expire : 2018-01-28 utilisation : S
ssb rsa4096/0xA0F83AE2EE071150
créé : 2017-01-28 expire : 2018-01-28 utilisation : E
[ ultime ] (1). Jean Deauh <[email protected]>

gpg> save

Là aussi il est possible d'utiliser pour ligne de commandes rapide introduite dans les versions récentes de GPG en utilisant l'empreinte de votre clef primaire :

gpg --quick-addkey E6D9DD35E0233198EFAF68F51C141B1DE773D6CA rsa4096 sign 1y
gpg --quick-addkey E6D9DD35E0233198EFAF68F51C141B1DE773D6CA rsa4096 encr 1y

Nous voilà donc avec une clef secrète composée d'une clef principale (sec) pour la certification (C) et de sous-clefs (ssb) pour la signature (S) et le chiffrement (E).

Notez que vous pouvez ajouter une ligne à votre fichier gpg.conf afin d'indiquer la clef à utiliser par défaut pour la signature. Cela passera par l'ajout suivant (à adapter selon l'ID de votre propre sous-clef de signature) :

default-key 0x7B0E97F0E71AF6AA

La sauvegarde de vos clefs

Passons maintenant à une étape importante : celle qui consiste à créer une sauvegarde de vos clefs. Ici, on passera par des fichiers qui sont à mettre en sécurité, mais il est possible de passer par des sauvegardes papier, sous forme de QR Code ou autre selon vos préférences. Des outils comme Kleopatra proposent même désormais directement une option d'impression :

Impression Clef GPG Kleopatra

Pour ces différentes étapes vous pouvez passer par des outils à interface graphique, mais là encore, la ligne de commandes nous permet une gestion unifiée et complète sur les différents systèmes d'exploitation. C'est donc vers elle que nous avons décidé de nous tourner.

  • Certificat de révocation

Celui-ci vous permettra de révoquer votre clef complète en cas de problème. Si jamais elle venait à être découverte ou perdue, il sera possible de l'utiliser pour indiquer qu'elle ne doit plus être utilisée.

Dans les versions récentes de GPG il est généré automatiquement, vous le retrouverez dans le répertoire openpgp-revocs.d situé dans celui contenant votre fichier gpg.conf (voir ci-dessus). Sinon vous pouvez toujours le générer avec la commande suivante (à utiliser avec le nom, l'ID, l'empreinte ou l'email) :

gpg --output revocation.asc --gen-revoke [email protected]

Notez que vous pouvez désigner une clef tierce afin de lui permettre de générer un certificat de révocation à travers la commande --desig-revok.

  • Clef primaire et sous-clefs

L'objectif est maintenant de garder une sauvegarde séparée de la clef primaire qu'il faut mettre en sécurité et les sous-clefs qui pourront être utilisées sur une machine du quotidien. Pour cela nous utiliserons deux commandes spécifiques (à utiliser avec le nom, l'ID, l'empreinte ou l'email) : 

gpg -a --export-secret-keys [email protected] > secret_keys.gpg
gpg -a --export-secret-subkeys [email protected] > secret_subkeys.gpg
  • Clef publique et envoi sur un serveur de clefs

Vous pouvez aussi plus simplement créer une sauvegarde de votre clef publique qui sera à partager largement. Pour cela, vous pouvez la mettre en copie de vos emails, sur votre site ou même la publier sur un serveur de clefs (en utilisant l'ID/empreinte de celle-ci). Attention, il sera impossible de la supprimer une fois en ligne. Vous pourrez seulement diffuser votre certificat de révocation pour indiquer qu'elle ne doit plus être utilisée.

gpg -a --export [email protected] > public.gpg
gpg --keyserver eu.pool.sks-keyservers.net --send-key 0x1C141B1DE773D6CA

L'utilisation de vos clefs sur une machine du quotidien

Maintenant que vous avez créé une sauvegarde de vos clefs, il vous reste à les mettre en place sur vos différentes machines, et à faire éventuellement le ménage sur celle que vous venez d'utiliser.

  • Suppression de la clef privée

Si l'on veut éviter que la clef privée reste sur la machine actuelle, il est possible de le faire via une commande simple (à utiliser avec le nom, l'ID, l'empreinte ou l'email). Il vous sera proposé de supprimer la clef primaire mais aussi les sous-clefs, attention donc à ce que vous aller accepter ou refuser.

gpg --delete-secret-keys [email protected]
  • Import des sous-clefs

Si vous voulez importer les sous-clefs sur une machine afin de pouvoir signer ou chiffrer des documents et des emails, vous pouvez utiliser un outil avec une interface graphique, ou la commande suivante (à utiliser avec le nom, l'ID, l'empreinte ou l'email) :

gpg --import secret_subkeys.gpg

Vous pourrez ensuite verifier l'état de vos clefs privées et publiques respectivement, avec les commandes suivantes :

gpg -K
gpg -k

Si la clef primaire est bien absente, vous le saurez avec la présence de la mention sec# lorsque vous afficherez les informations sur vos clefs privées.

Retrouvez notre dossier Chiffrement, clefs de sécurité et cryptobidules :

70

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Renforcer l'environnement depuis lequel la clef est générée

L'importance de disposer de sous-clefs

Création de la clef de base

Ajout des sous-clefs de chiffrement et de signature

La sauvegarde de vos clefs

L'utilisation de vos clefs sur une machine du quotidien

Commentaires (70)


pourquoi utiliser RSA plutôt que quelque chose de moins commun et donc moins susceptible d’être attaqué comme par exemple blowfish ?



personnellement j’utilise blowfish comme algo de chiffrement de ma base de mots de passe keepass (nécessite un plug-in)


On ne peut pas désactiver 3DES car c’est le cipher qui permet une compatibilité entre toutes les versions. C’est également la même chose pour md5 ou sha1 je crois.








neojack a écrit :



pourquoi utiliser RSA plutôt que quelque chose de moins commun et donc moins susceptible d’être attaqué comme par exemple blowfish ?



personnellement j’utilise blowfish comme algo de chiffrement de ma base de mots de passe keepass (nécessite un plug-in)







Blowfish et RSA ne sont pas le même type d’algo et ils n’ont pas le même usage.

Blowfish est un algo de chriffrement symetrique ou la même clé sert à chiffrer et déchiffrer.

RSA est un algo asymétrique fonctionnant avec une paire de clé dont l’une sert à chiffrer et l’autre à déchiffrer.

On va plutôt utiliser blowfish pour les trucs à chiffrer et qu’on va garder pour soi-même alors que RSA va plutôt être utilisé pour l’échange d’information.



Au lieu de RSA, il aurait pu être conseillé d’utiliser ECC (courbes elliptiques) plutôt…



Comme dit pour ECC c’est un choix que chacun peut faire. Après je sais que dans le cas de GPG ce n’est pas privilégié par certains pour différentes raisons, et comme RSA reste relativement utilisé ça me semblait un meilleur choix par défaut <img data-src=" />


Merci pour ce tuto! Le chiffrement des communications devrait d’ailleurs être un prérequis pour tous les journalistes <img data-src=" />








neojack a écrit :



pourquoi utiliser RSA plutôt que quelque chose de moins commun et donc moins susceptible d’être attaqué comme par exemple blowfish&nbsp;&nbsp;



Croire que parce que c’est moins commun, ce sera moins attaqué, c’est une erreur qui profite à l’assaillant.

Dans le cas du logiciel libre, ce qui est plus utilisé sera plus audité, donc moins à même de laisser planer des erreurs qui génèrent les failles.

Pour le chiffrage, l’open-source (de préférence autocompilé) est d’une réelle importance.



On dit chiffrement et pas chiffrage.








David_L a écrit :



Comme dit pour ECC c’est un choix que chacun peut faire. Après je sais que dans le cas de GPG ce n’est pas privilégié par certains pour différentes raisons, et comme RSA reste relativement utilisé ça me semblait un meilleur choix par défaut <img data-src=" />







Le souci de RSA est que sa force est liée à la taille de la clé et on arrête pas de devoir faire grossir les clés pour le conserver. Sans être un spécialiste du sujet (et loin s’en faut), il me semble que les algos ECC (car c’est une famille de pleins d’algos en fait) n’ont pas ce problème et sont plus pérennes pour ça.

Mais bon, dans le cas spécifique de GPG, je ne sais pas ce qui est le mieux et je suis bien content de lire ce genre d’article. Ils ont très certainement plein de bonnes raisons pour préférer encore RSA par rapport à ECC :)




Faut-il encore compiler son compilateur pour être sûr qu’il n’est pas lui même infecté. Mais du coup, il faut encore compiler le compilateur qui servira à compiler le compilateur pour être sûr qu’il n’est pas lui même infecté. Et la encore, il faut compiler le compilateur qui servira à compiler le compilateur qui servira à compiler le compilateur…<img data-src=" />


Suffit d’écrire ton propre compilateur en langage machine.

Par contre par sécurité, je te conseille de monter toi-même ta machine avec des composants que tu aura toi-même fabriqués, les failles ne sont pas que logicielles…


La clé chaude: Une paire de c……s presque parfaite <img data-src=" />


clap clap pour le tuto !



ça reste difficilement accessible pour les mortels non informaticiens.


C’est toujours une question de point de vue, mais sur le fond, y’a un fichier à éditer, 45 lignes à taper (surtout avec les commandes rapides) et rien de très complexe à comprendre. Alors oui c’est plus que de ne rien faire, mais franchement dans mes 25 ans à tapoter sur un clavier, j’ai déjà rencontré bien plus compliqué <img data-src=" />








tazvld a écrit :



Faut-il encore compiler son compilateur pour être sûr qu’il n’est pas lui même infecté. Mais du coup, il faut encore compiler le compilateur qui servira à compiler le compilateur pour être sûr qu’il n’est pas lui même infecté. Et la encore, il faut compiler le compilateur qui servira à compiler le compilateur qui servira à compiler le compilateur…<img data-src=" />





Qui surveille le surveillant qui surveille ?&nbsp;<img data-src=" />



est il prévu d’afficher votre clé public quelques part ? pour chiffrer le signalement d’une erreur par exemple, ou envoyer des infos sur un bullgate, c’est pour un ami <img data-src=" />.



ouais je sais ca sert a rien mais ne faut il pas commencer par un commencement ? et qu’elle joie de chiffrer des messages avec d’autre personnes que sois même et son frère <img data-src=" />


Les clefs de membres de l’équipe ou lien vers celles-ci sont déjà intégrées dans les blocs auteur lorsque disponible ;)&nbsp;


Malheureusement, l’ECC est plus vulnérable aux attaques par ordinateur quantique que le RSA (du fait de la petite taille des clés). En attendant les algo post-quantiques, le mieux reste donc une bonne grosse clé RSA (genre 8192 bits).

&nbsp;En plus, ça évite de mettre dans l’embarras les gens qui sont coincés sur une vieille version de GnuPG (il me semble que l’ECC n’est supporté que dans les versions 2.1+)


Il n’existe pas d’interface graphique pour faire tout ça ! Pas très sérieux GPG !


Oui pour ECC, mais 8192 bits peut aussi poser des soucis de compatibilité.&nbsp;


Sur une version fraichement installée de GPG suite sur macOS Sierra (2017.1b2) :



&gt; gpg –full-gen-key –expert

gpg: option « –full-gen-key » incorrecte



Et l’option weak-digest SHA1 dans gpg.conf n’est pas acceptée.



Du coup, la procédure de création de la clé n’est pas du tout la même que celle indiquée.



EDIT : ça vient probablement de la version installée par défaut, qui n’est pas la 2.1 :

&gt; gpg –versiongpg (GnuPG/MacGPG2) 2.0.30


“Utilisez-donc cet exécutable non open-source pour optimiser la sécurité de vos réglages”



&nbsp;O_O’



Sérieux?

Il est où le GitHub?








bugmenot a écrit :



Malheureusement, l’ECC est plus vulnérable aux attaques par ordinateur quantique que le RSA (du fait de la petite taille des clés). En attendant les algo post-quantiques, le mieux reste donc une bonne grosse clé RSA (genre 8192 bits).

&nbsp;En plus, ça évite de mettre dans l’embarras les gens qui sont coincés sur une vieille version de GnuPG (il me semble que l’ECC n’est supporté que dans les versions 2.1+)







Encore faudrait il que l’ordinateur quantique existe et fonctionne…









linconnu a écrit :



Il n’existe pas d’interface graphique pour faire tout ça ! Pas très sérieux GPG !







Si il y en a plein mais c’est pas opengpg qui s’en occupe car ils ont déjà assez de boulot avec leur propre projet



En effet, mais bon, depuis le temps que des gens se baladent avec des clés de 8kbits, en pratique les problèmes sont rares ;)&nbsp; Aucun souci en particulier avec GnuPG 2.x, et je ne crois pas non plus avec les dernières versions 1.x


Il y a par exemple Kleopatra (disponible sous Windows via Gpg4win)


Quand l’existence d’un ordinateur quantique suffisamment gros pour cracker les clés sera confirmée, ça sera trop tard…

Et il semble que les progrès sont assez palbables quand même :https://www.wired.com/2015/09/googles-quantum-computer-just-got-a-big-upgrade-10…


dans ma flemme, mais je doutais que les sources d’un outil qui sert à ouvrir un notepad seraient demandées si rapidement ;) Je rajoute dès que je prend le temps de publier :)


Quel est le but de ces articles sur une technologie aussi désuète que PGP?A part faire jouir quelques aficionados qui seront fiers de recevoir des emails cryptés sans aucun intérêt mais avec le plaisir de dire ça y est, je l’ai fait!GPG a fait son temps, un protocole vieillot ,mal ficelé et dénoncé de toutes parts par les geeks experts:



“The protocol reflects layers of cruft built up over the 20 years that it took for cryptography (and software engineering) to really come of age, and the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy.”

&nbsp;Moxie Marlinspike, Expert en cryptologie, créateur de la messagerie Signal &nbsp;,&nbsphttps://moxie.org/blog/gpg-and-me/



“It’s time for PGP to die.”&nbsp;https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/Matthew Green, cryptographer and professor at Johns Hopkins University.&nbsp;



Envoyez vos messages confidentiels avec Signal, même votre grand mère peut l’utiliser!








foregone a écrit :



Quel est le but de ces articles sur une technologie aussi désuète que PGP?A part faire jouir quelques aficionados qui seront fiers de recevoir des emails cryptés sans aucun intérêt mais avec le plaisir de dire ça y est, je l’ai fait!GPG a fait son temps, un protocole vieillot ,mal ficelé et dénoncé de toutes parts par les geeks experts:



“The protocol reflects layers of cruft built up over the 20 years that it took for cryptography (and software engineering) to really come of age, and the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy.”

&nbsp;Moxie Marlinspike, Expert en cryptologie, créateur de la messagerie Signal &nbsp;,&nbsphttps://moxie.org/blog/gpg-and-me/



“It’s time for PGP to die.”&nbsp;https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/Matthew Green, cryptographer and professor at Johns Hopkins University.&nbsp;



Envoyez vos messages confidentiels avec Signal, même votre grand mère peut l’utiliser!







Et tu proposes quoi pour les mails ?



Pour ceux qui ont gpg4win (donc gpg 2.0.x), qui avaient déjà des clés présentes, et qui voient leur trousseau vide: il suffit de commenter ou de virer l’option weak-digest de gpg.conf pour que vos clés réapparaissent comme de par magie…


ma grand-mère n’a pas de smartphone et n’en veux pas, donc exit signal.

GPG, lui, a au moins la décence d’être un protocole qui n’utilise pas les serveurs de google et qui peux fonctionner sous android, ios, linux, mac, windows, unix, etc. et qui a même un addon sous thunderbird…

signal, t’est obligé d’utiliser leur app, ce qui limite à l’extrême (chrome, android et ios seulement)


Quand tu ne veux pas partager ton numéro de tél ou lier ta clef à une smartcard, Signal montre plutôt ses limites, non ? Pourquoi vouloir opposer des technos, alors que chacune correspond à des usages de manière complémentaire ? A mon sens, c’est plus ça l’erreur à ne pas faire, que d’utiliser telle ou telle solution.


Tu peux utiliser la version bêta de GPG4Win, donc la 2.1.x ;)


Rien de la sorte sous macOS ? GPG Suite est toujours en 2.0.X.


GPG Suite n’est de toutes façons pas totalement compatible avec Sierra, ce qui est un autre problème…&nbsp;



Pour le reste ;)&nbsp;https://gnupg.org/download/index.html


La nouvelle beta publique sortie le 2301 est enfin compatible Sierra. Mais c’est toujours la version 2.0.30 qui y est intégrée.


Oui ça reste en bêta pour le moment. Mais rien n’empêche d’utiliser GPG 2.1.x sur macOS, c’est un logiciel indépendant d’un éventuel package ;)


Avec PGP tu signes tout et n’importe quoi sur n’importe quelles plateformes. Tu peux signer et chiffrer du texte, des fichiers, des clés etc.

PGP permet aussi de signer les clés d’autres personnes ce qui permet de créer un maillage de confiance (aussi appelé toile de confiance), c’est plus que pratique quand tu cherches à intégrer un réseau où la confiance est essentielle.

Par exemple les gestionnaires du dépot debian utilisent ce système. Les développeurs d’application de sécurité critique également.

PGP est également la norme sur le deep web (tor, i2p et très certainement freenet), qui ne sert pas qu’au contenu pédophile et autres trucs horribles, mais aux réseaux de journalistes et activistes politiques.

Bref, PGP est à des années lumières de ce que propose signal et surtout n’a pas le même usage.








foregone a écrit :



&nbsp;Moxie Marlinspike, Expert en cryptologie, créateur de la messagerie Signal &nbsp;,&nbsp;https://moxie.org/blog/gpg-and-me/





j’ai mes réserves envers signal et plus spécifiquement la façon dont Moxie gère signal.

Il prétend que c’est pus sécure de faire confiance a google et a des logiciels non-libre (comme par exemple le Google Cloud Messaging).

&nbsp;

Je l’ai déjà dit mais je suis un utilisateur de réplicant et c’est le seul système que l’on peut considéré comme étant sur de ne pas faire partie d’un botnet quelconque (et divers fonction malveillant), donc le seul sur lequel on peut commencer a avoir une confiance pour les communication chiffrer.

&nbsp;

Évidement mon commentaire implique qu’il est inutile de crypter sur des téléphone qui aurait une once de blob quelque part et que dans ce cas des solution chiffre son inutiles.

C’est vrai mais cela ne veut pas dire qu’il ne faut pas faire de logiciel de chiffrage.

&nbsp;

Je trouve que c’est une peut naïfs de la de Moxie de faire confiance a des solutions et des logiciel non-libre on sais très bien que cela cause beaucoup de problème.



De plus j’apprécie pas comment Moxie gère la communauté autour de son logiciel.

Moxie ne veut pas faire un paquet pour F-droid et force les gens a utiliser a google play.

Il est persuader que les blocages de google sur les téléphone sont bénéfique a l’utilisateur.

Je suis aussi déçu de Moxie car il a refuser que libresignal puisse exister.

je trouve que la façon de considérer les gens comme de simple ignare (même si c’est vrai) n’est pas une bonne façon de procéder.

Je pense que la bonne et fatigante façon de procéder c’est de faire en sorte que les gens s’intéresse un peut plus a leur outils, non pas forcement au point qu’ils aillent eu même compiler le logiciel (quoi que on peut dire huzza le jour ou ça arrive), mais au moins qu’ils sachent utiliser un système simple comme GPG, car oui GPG est je trouve très, très simple d’utilisation de nos jour.

&nbsp;

Il est aussi persuader que la centralisation c’est bien (ça dépend des cas)

Perso je déconseille pas signal en soit, car c’est bien d’avoir ce genre de logiciel, mais je déconseille de l’utiliser temps qu’il est sous le joue de Moxie.





Bref je vais aller voir du coté de&nbsp; conversation.



“Si vous êtes sous Windows, nous avons créé un petit utilitaire vous

permettant d’ouvrir ce fichier afin de le modifier sans avoir à fouiller

dans des dossiers cachés. Il est disponible par ici.”



Je veut pas faire mon sucrer mais….

C’est possible d’avoir une copie du code source du .exe s’il vous plaît :3








Carpette a écrit :



Avec PGP tu signes tout et n’importe quoi sur n’importe quelles plateformes. Tu peux signer et chiffrer du texte, des fichiers, des clés etc.

PGP permet aussi de signer les clés d’autres personnes ce qui permet de créer un maillage de confiance (aussi appelé toile de confiance), c’est plus que pratique quand tu cherches à intégrer un réseau où la confiance est essentielle.

Par exemple les gestionnaires du dépot debian utilisent ce système. Les développeurs d’application de sécurité critique également.

PGP est également la norme sur le deep web (tor, i2p et très certainement freenet), qui ne sert pas qu’au contenu pédophile et autres trucs horribles, mais aux réseaux de journalistes et activistes politiques.

Bref, PGP est à des années lumières de ce que propose signal et surtout n’a pas le même usage.





+_+



+1, Signal est une vaste blague qui t’oblige à utiliser Google. Partant de là, pas grand chose à ajouter. A part que c’est une question d’usage: ça reste approprié pour sécuriser (faiblement) les SMS et les appels (et encore, pour les SMS il y a SIlence). Pour le reste, PGP ne me semble pas avoir de concurrent…&nbsp; “Avec PGP tu signes tout et n’importe quoi sur n’importe quelle plateforme”, ça résume bien








bagofgnutea a écrit :



Je veut pas faire mon sucrer mais….





Juste comme ça, ça veut dire quoi « faire son sucrer » ?



Voir ma réponse plus haut ;)


dans le contexte, j’hésite entre tatillon et relou (en fonction du ton). Sinon c’est par opposition à “être salé” (de l’anglais salty qu’on traduirait en français par amer plutôt) mais ça n’aurait aucun sens :P

(perso j’aurais écrit “sucré”, si j’avais connu ce mot mais je suis peut-être tatillon <img data-src=" />)

/minute_linguistique


Admettons que GPG c’est mal pour les mails … .



As-tu une bonne alternative (rapide simple tout ça) à nous proposer quand il s’agit de chiffrer des fichiers sur ton PC ou ton disque dur de sauvegarde … ie quand ta motivation de chiffrement n’est pas … la messagerie ?


Merci beaucoup pour le tuto :)


Je me suis rendu compte que ma clé n’a pas de date d’expiration, c’est grave ?








Vekin a écrit :



Je me suis rendu compte que ma clé n’a pas de date d’expiration, c’est grave ?





Ca se change facilement. Non ce n’est pas “grave” en soi mais la plupart des gens serieux refuseront de signer une telle cle. L’idee de la date d’expiration est d’avoir un recours en cas de vol de la cle privee et/ou de disparition de l’auteur original. L’idee etantde rajouter 12 ans de plus quand on arrive a la date d’expiration.

Dans mon cas, mes cles sont valides 2 ans au terme desquels je rajouterai 2 ans et ainsi de suite.



Donc au lieu de recréer une nouvelle clé, tu étends l’expiration arrivé à terme ? C’est plutôt malin. Bon dans les deux cas, les contacts doivent retélécharger la clé publique.








Vekin a écrit :



Donc au lieu de recréer une nouvelle clé, tu étends l’expiration arrivé à terme ? C’est plutôt malin. Bon dans les deux cas, les contacts doivent retélécharger la clé publique.





Exact, changer la date d’expiration ou toute autre info implique de regenerer une nouvelle cle publique.



La clef privée n’a de toutes façons jamais d’expiration effective, tu peux donc modifier la à tout moment ;) (mais c’est mieux d’en avoir une, en cas de perte de la clef privée et du certificat de révocation ça permet d’avoir une protection complémentaire pour indiquer à des tiers de ne plus l’utiliser <img data-src=" />)


On peut donc avoir une date d’expiration différente sur la clé privée et publique ? Je ne savais pas <img data-src=" />


Non (seulement pour les sous-clefs) mais sur la clef privée c’est inopérant :) Le but est surtout de dire que si la date est dépassée sans être modifiée, il ne faut plus utiliser la clef publique.



Au passage depuis la 2.1.17 il existe une option&nbsp;–quick-set-expire pour changer rapidement la date d’expiration d’une clef.


Il me semble plus précisément que ça implique de resigner la clé publique, pas de la regénérer (la différence s’apprécie, vu le temps qu’il faut pour générer une grosse clé comme celles que j’utilise ;) )


Merci de me corriger, je n’ai pas encore etudie les details de GPG.



Donc le process consisterait a prendre la cle publique liee a la cle en question (primaire ou sous cle), d’y ajouter les infos en question et de signer le tout avec sa cle privee ? Effecivement ca parait pas idiot.


J’ai réussi à créer ma clé maître, mais ça aurait été bien que l’article indique comment trouver le cerbère de la porte <img data-src=" />








David_L a écrit :



<img data-src=" />







Flagrant délit d’inculture.



Merci à vous pour ce dossier très intéressant mis en favori instantanément chez moi.

Je m’étais déjà frotté un peu (trop peu ?) à GPG mais le problème pour moi c’est les autres : si je suis le seul à l’utiliser et qu’aucun proche ne s’y met cela présente peu d’intérêt… (toujours le même problème)



Un peu HS, quelqu’un a un bon dossier pour chiffrer une /home sous debian ?


Debian le propose par défaut avec LUKS non ? (De mémoire ça peut être fait ensuite avec Cryptsetup, mais sans doute à creuser) <img data-src=" />


Tout à fait possible mais il me semble que cela présente quelques inconvénients, du moins dès lors que l’on utilise ma méthode automatique.


Il faut bien que certains commencent ;)

&nbsp;

Sinon à une cryptopartie, j’avais discuté avec quelqu’un qui signait systématiquement ses e-mails avec PGP (sans les chiffrer, car on ne le mentionne pas souvent mais on peu aussi utiliser PGP pour papoter en clair tout en certifiant que le texte n’a pas été altéré, cf les mailing lists de Freenet par exemple)

Du coup, ça intriguait certains destinataires et c’était l’occasion d’engager la discussion sur le sujet :)


Un des truc qui peut porter à confusion avec GPG (enfin je trouve), c’est qu’au final les clés sont plus que des clés, ce sont des “certificats” avec des signatures. Pour aller plus dans le détail (mais très technique), une petite commande utile :&nbsp;

&gt;&nbsp;gpg -a –export (maclé) | gpg –list-packets

&gt; gpg -a –export-secret-key (maclé) | gpg –list-packets


C’est bien ce que je disais.

Vraiment un truc de geeks ayant du temps à perdre, les emails PGP, non seulement vous ne trouverez personne à qui envoyer vos mails chiffrés de surcroît sans intérêt réel à être chiffré, mais vous pouvez aboutir à ce genre de situation désespérée, signer tous ses emails pour susciter l’intérêt!!!



Comment peut on être fier en 2017 de faire toute une gymnastique avec des clients pourris , un système de keychain obsolète pour envoyer de simples messages?



Pour les emails , PGP GPG c’est obsolète et une pure perte de temps.


C’est une perte de temps pour les rien-à-cacher. Autrement, c’est tout simplement state-of-the-art. A moins que tu aies une alternative à nous présenter ? (peut-être Dark Mail? mais c’est encore bien jeune et encore moins répandu)


Malheureusement le gpg ne gère pas la confidentialité persistante. Si on nous vole la clés les précédents messages peuvent être déchiffré, ce qui rend gpg difficilement utilisable dans le cadre de communications type chat 😞



https://blog.oodrive.fr/blog/2015/03/27/securiser-les-communications-sur-interne…