GnuPG 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés

GnuPG 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés

\o/

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

29/08/2017 10 minutes
40

GnuPG 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés

Pendant l'été, GnuPG a subi plusieurs mises à jour. La dernière en date ne paie pas de mine, mais elle augure de la prochaine branche stable 2.2.0 de l'outil de chiffrement. Elle active ainsi par défaut des fonctionnalités simplifiant l'échange de clés lors d'un premier contact.

Dans la série « on vous annonce des trucs énormes, mais on le fait l'air de rien », notre gagnant du moment est l'équipe de GnuPG. Il faut dire qu'elle est une habituée du genre.

Après une version 2.1.21 qui corrigeait principalement des bugs et autres failles de sécurité, nous avons a eu droit fin juillet à la 2.1.22 qui apportait quelques nouveautés, surtout une reconnaissance automatique de la présence de Tor sur le système. S'il est détecté, il est désormais automatiquement utilisé, excepté si l'utilisateur utilise l'argument --no-use-tor.

Début août, c'est la version 2.1.23 qui a été mise en ligne, une mouture qui va changer la donne. Et pour cause, il s'agit en réalité d'une release candidate pour la version 2.2.0 qui doit devenir à terme la nouvelle branche stable.

gpg2, c'est fini

Pour rappel, trois branches de GnuPG coexistent. Chacune propose un niveau de fonctionnalités différent et permet d'assurer un support à plus ou moins long terme selon les besoins : Classique (1.4.x), Stable (2.0.x) et Moderne (2.1.x).

La branche stable actuelle sera considérée comme en fin de vie le 31 décembre 2017. D'ici là, elle devra donc être remplacée par la 2.2.x qui commence à se dévoiler. Et le premier changement majeur qu'elle apporte est la fin de gpg2.

En effet, selon les cas, il existait jusqu'à maintenant deux exécutables installables sur le système. Le second était gpg qui sera désormais utilisé par défaut. Les adeptes de l'ancienne méthode ou ceux disposant d'applications qui nécessitent une continuité peuvent utiliser le paramètre --enable-gpg-is-gpg2 s'ils le souhaitent.

On compte aussi d'autres petites nouveautés :

  • --no-grab est activé par défaut pour éviter les attaques de type X-Sniffing
  • --disable-dirmngr permet de désactiver complètement les accès réseau de GnuPG
  • show-only peut être utilisé lors d'un import pour montrer le résultat, sans action

Dans ce dernier cas, la commande exacte à utiliser est la suivante : 

gpg --import --import-options "show-only" clef.gpg

La révolution est dans la distribution

Mais le plus grand changement vient de la méthode de distribution des clés, qui se prépare à évoluer de manière importante. En effet, GnuPG est critiqué de longue date pour sa complexité, notamment dans la gestion et le partage des clés publiques avec des tiers (voir notre analyse).

Le système actuel repose sur deux grands principes : les serveurs de clés publiques et la toile de confiance (Web Of Trust, ou WOT) qui permet à chacun d'indiquer le niveau de confiance qu'il accorde à telle ou telle clé. Mais il permet à n'importe qui de publier une clé pour n'importe quelle identité/adresse email. De plus, il rencontre de nombreuses limites pratiques, notamment lors d'un premier contact. De quoi réduire sa capacité à être utilisé par le plus grand nombre.

Au fil du temps, différentes méthodes ont été tentées. Une clé publique étant un simple fichier texte, il peut être transmis de bien des manières. Récemment, ce sont les enregistrements DNS qui ont été exploités, notamment via DANE (DNS - based Authentication of Named Entities). Mais la faible évolution des pratiques en la matière, notamment chez les hébergeurs, a presque tué dans l'œuf une telle solution.

Il a donc été mis de côté pour le moment, même si l'utilisation de DANE reste une solution évoquée par l'équipe sur le long terme, notamment dans le cadre de la mise en place de son nouveau protocole de distribution.

TOFU et Web Key Service, c'est le turfu !

Car lorsqu'elle a reçu de nouveaux financements, l'équipe de GnuPG a décidé de travailler sur la refonte de ces deux grands principes en priorité. Ainsi, plusieurs éléments sont mis en place progressivement.

Pour le modèle de confiance, c'est TOFU (Trust On First Use) qui devra prendre place dans les mois à venir. Il est possible de le tester depuis la version 2.1.10. Pour la distribution des clés, c'est le protocole Web Key Service (WKS) et ses Web Key Directory (WKD) dont il est question.

Dans les deux cas, le but recherché est le même : faciliter l'échange de clés entre deux personnes qui se contactent pour la première fois, et qui n'ont donc pas à disposition dans leur trousseau local leurs clés publiques respectives. C'est cet ensemble qui se met en place petit à petit auquel nous commençons à avoir droit à travers cette version 2.1.23, qui active par défaut deux arguments qui étaient jusqu'à maintenant optionnels.

  • GPG Web Key Service
  • GPG Web Key Service
  • GPG Web Key Service
  • GPG Web Key Service

La récupération automatique pour vérifier une signature

Le premier est --auto-key-retrieve. Comme son nom l'indique, il permet de récupérer automatiquement la clé d'un tiers à travers les serveurs de clés publics, afin de permettre de vérifier simplement une signature.

Imaginons que vous téléchargiez la dernière version de votre distribution Linux préférée ou une application. Avec le fichier principal, les développeurs publient en général une signature permettant à un tiers de s'assurer qu'ils sont bien à l'origine du fichier téléchargé et que celui-ci n'a pas été altéré (voir notre analyse).

Ainsi, vous pouvez vérifier simplement la validité de l'ISO d'Ubuntu 17.04 via la commande suivante : 

gpg --verify SHA256SUMS.gpg ubuntu-17.04-desktop-amd64.iso

Problème : vous ne disposez pas de la clé publique des développeurs d'Ubuntu. Jusqu'à maintenant, la procédure à suivre était de la télécharger pour l'importer dans votre trousseau local (via la commande gpg --fetch). Désormais, tout est automatique, tant que cette clé est présente au sein d'un serveur public. 

GnuPG va automatiquement récupérer l'ID de celle qui a servi à générer la signature, et la télécharger. Le résultat vous sera alors affiché et la clé sera importée dans votre trousseau. Vous aurez alors la possibilité de la supprimer, ou de modifier votre niveau de confiance si vous avez pu vérifier sa véracité :

GnuPG Import Auto RetrieveGnuPG Import Auto Retrieve
Avant / Après GnuPG 2.1.23

L'équipe a néamoins décidé de revenir en arrière pour éviter certains problèmes évoqués dans cet email, et de désactiver ce paramètre par défaut dans la prochaine version de GnuPG. Une version 2.1.23-1 a aussi été poussé dans la branche Unstable de Debian. Il restera tout de même possible de l'activer à la demande.

La récupération automatique pour chiffrer un message

L'autre argument mis en place par défaut est --auto-key-locate "local,wkd". Celui-ci implique que lorsque vous chiffrerez un message pour une adresse email précise, la clé publique sera cherchée dans votre trousseau local, et à défaut dans une Web Key Directory définie dans le protocole Web Key Service.

Derrière ce nom se cache un nouveau concept proposé comme standard à l'IETF par le développeur principal de GnuPG, Werner Koch. L'idée est de proposer de retrouver les clés liées à un domaine directement via des fichiers présents dans un répertoire à l'emplacement prédéfini (well-know URI).

Ainsi, lorsque vous décidez de chiffrer un message pour [email protected], sans disposer de la clé publique associée, GnuPG va aller interroger le fichier suivant afin d'y trouver la clé publique, et l'importer si elle correspond : 

https://jeandauh.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga

Cette URL peut aussi être utilisée dans les données d'une OpenPGP Card afin de permettre de récupérer votre clé publique au sein d'une nouvelle machine (voir notre guide).

L'ID de fin est constituée de 32 caractères issus d'une empreinte SHA-1 de la partie locale de l'email (ici, me) encodée via Z-Base32, qui est une version spécifique de Base32 se voulant plus simple à appréhender et à gérer pour un utilisateur, notamment en évitant les confusions possibles entre certains caractères. 

Notez qu'un enregistrement DNS SRV peut être utilisé afin d'indiquer un domaine ou un port différent. On regrettera par contre qu'une telle fonctionnalité ne soit pas proposée de manière plus générale, notamment à travers la commande --fetch qui pourrait aller chercher la clé liée à un email précis dans la Web Key Directory afin de simplement l'ajouter au trousseau local sans autre action complémentaire.

La simplicité n'est pas la sécurité

Le chiffrement de la connexion via HTTPS doit être supporté par le serveur. À l'heure de Let's Encrypt, il est souvent proposé par défaut par les hébergeurs qui permettent de le mettre en place assez simplement.

Ainsi, on est assuré que le fichier transmis est bien celui présent sur le serveur, et qu'il n'a pas pu être altéré par un tiers pendant son téléchargement. Attention néanmoins, si une personne mal intentionnée venait à avoir accès à votre serveur, elle pourrait aisément modifier ce fichier, et donc se faire passer pour vous.

C'est notamment pour cela que WKS/WKD est présenté comme une manière de simplifier la distribution lors d'un premier échange, mais pas de revoir le modèle de confiance sur le fond. Ainsi, la toile de confiance permet toujours de s'assurer de la véracité d'une clef sur le long terme, avec le témoignage d'une multitude de tiers.

Il est donc toujours important de certifier des clés dont vous avez pu assurer la validité, afin de faire vivre ce modèle de confiance décentralisée. Bien entendu, vous pouvez aussi vous baser sur différentes déclarations effectuées par un utilisateur à travers des services comme Keybase.io (voir notre analyse).

L'objectif final : motiver les hébergeurs et les services de messagerie

La méthode des Well-kown URI n'a rien de bien nouveau. Elle est notamment utilisée par Keybase pour valider la propriété d'un domaine ou encore par Do Not Track. Chacun peut bien entendu publier sa clé sur son propre serveur (voir notre guide ci-dessous), mais le but de l'équipe de GnuPG est d'inciter les hébergeurs et autres fournisseurs de services d'email à proposer directement ce service.

Le protocole WKS intègre ainsi tout un dispositif permettant à un utilisateur de transmettre sa clé publique à son gestionnaire d'email pour que celui-ci la publie directement via WKD ou DANE. Là aussi, cela passe par une adresse prédéfinie, qui peut être reconnue et utilisée par des outils tiers. Un début d'intégration, détaillé par l'équipe de GnuPG, est d'ailleurs présent dans les nightly builds d'Enigmail.

Malheureusement, pour le moment seul le service Posteo propose l'embryon d'une telle fonctionnalité. Espérons qu'avec l'arrivée de cette version 2.1.23, puis de la future branche 2.20, les différents services commenceront enfin à jouer le jeu comme ils ont pu le faire avec la mise en place progressive de Let's Encrypt.

Ces derniers cherchant à inciter leurs utilisateurs à moins dépendre des GAFAM et à reprendre en main leurs données, nul doute que cela ne saurait tarder. Surtout que l'implémentation du protocole WKS proposé par GnuPG est relativement triviale pour leurs équipes. C'est en tous cas un point que nous suivrons avec attention dans les mois à venir.

40

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

gpg2, c'est fini

La révolution est dans la distribution

TOFU et Web Key Service, c'est le turfu !

La récupération automatique pour vérifier une signature

La récupération automatique pour chiffrer un message

La simplicité n'est pas la sécurité

L'objectif final : motiver les hébergeurs et les services de messagerie

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (40)






  • récupérer automatiquement la clé d’un tiers à travers les serveurs de clés publics



    • retrouver les clés liées à un domaine directement via des fichiers présents dans un répertoire à l’emplacement prédéfini (well-know URI).





      Bref, ils ont automatisé ce qu’on fait tous quand on veux chercher une clé (ou un md5, ou une adresse email…): on va chercher l’information sur le web à un endroit qu’on considère arbitrairement “de confiance”.



      Bref, c’est la mort du “Web Of Trust” et le retour du “I Know What I’m Doing”.



Bravo, tu viens de découvrir la différence entre un standard et la bidouille <img data-src=" /> Pour le reste, tu as du mal lire, puisque ce n’est en rien la mort du WOT, mais plutôt un complément pour la phase de découverte qui reste un des points de friction essentiel (sans pouvoir remplacer le modèle de confiance sur le fond)


Hmm…. Pas d’accord.



“WoT = establish the authenticity of the binding between a public key and its owner.”



Laisser le logiciel télécharger une clé depuis une URL quelconque (qui n’est même pas une Autorité de Certification ou un site ayant pignon sur rue) n’apporte aucun niveau de confiance



https://davlgd.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga



WHOIS davlgd.fr





nic-hdl: ANO00-FRNIC

type: PERSON

contact: Ano Nymous

remarks: ————– WARNING ————–

remarks: While the registrar knows him/her, this person chose to restrict access to his/her personal data.

remarks: So PLEASE, don’t send emails to Ano Nymous.

remarks: This address is bogus and there is no hope of a reply.

remarks: ————– WARNING ————–

registrar: OVH

changed: 04/01/2011 anonymous@anonymous

anonymous: YES





La seule chose qui me donne confiance dans le lien que tu as donné, c’est qu’il est posté dans une news rédigée par ton compte sur le site nextinpact.com. <img data-src=" />


Le pire c’est qu’on est d’accord. Je reprend tes terme entre guillemets:





  1. WKD n’établit aucune “confiance sur le fond ” mais néanmoins permet techniquement d’utiliser GPG pour écrire à une adresse email quelconque.



  2. “tu as déjà confiance dans cette adresse” email quelconque à laquelle tu vas écrire.



    Moralité, tu as confiance dans l’adresse email et tu peux techniquement utiliser GPG pour écrire a cette adresse email =&gt; pourquoi se faire chier avec le WoT dans ce cas ?


Moi je balance ma clé GnuPG dans l’enregistrement TXT de mon DNS. <img data-src=" />


WKD n’est pas une question de confiance, mais de distribution. Cela permet d’automatiser le processus de premier contact à travers un canal sécurisé et simple à mettre en place.



Le WOT permet de vérifier qu’une clé (et non un email) et certifiée par d’autres ou non, et éventuellement de la certifier soi-même si on a pu la vérifier d’une manière ou d’une autre avec la personne concernée. Tu peux récupérer une fausse clé via WKD si le serveur est compromis.



Le WOT est là pour te permettre de t’en apercevoir simplement ou au moins de douter de la véracité de la clé si aucune certification tierce ne vient la confirmer, et donc de procéder à des vérifications complémentaires.&nbsp;



Pour rappel, l’email est une partie d’une identité d’une clé, pas son élément principal. Tu peux avoir 50 clés avec différentes identités et parfois une même adresse email.


Et personne n’a de moyen simple de la récupérer (de mémoire GPG proposait une méthode de récupération du genre via PKA mais elle a été dépréciée il y a un moment)








David_L a écrit :



Et personne n’a de moyen simple de la récupérer (de mémoire GPG proposait une méthode de récupération du genre via PKA mais elle a été dépréciée il y a un moment)





Un script avec dig en bash.<img data-src=" />

Bon, j’avoue que ça n’a pas d’intérêt à part pour 2 geeks. Mais l’idée aurait du être creusée selon moi, surtout avec DNSsec (et DANE), pas mal niveau sécu et intégrité.

Juste l’enregistrement TXT doit faire 1024 signes, pas plus et découpé par tranche de 255.



Tu peux diffuser déjà ta clef via un enregistrement DNS / DANE (avec les paramètres cert, pka ou dane de l’argument –auto-key-locate). Après il faut juste disposer d’un serveur DNS qui le propose (pas franchement pratique à gérer soi-même) ou d’un hébergeur qui le permet (rarement le cas). C’est notamment pour ça que d’autres pistes ont été creusées comme je l’explique dans le papier, même si DANE reste un élément qui est dans le scope de ce que prévoit l’équipe de GPG via le protocole WKS (voir les slides)








David_L a écrit :



Tu peux diffuser déjà ta clef via un enregistrement DNS / DANE (avec les paramètres cert, pka ou dane de l’argument –auto-key-locate). Après il faut juste disposer d’un serveur DNS qui le propose (pas franchement pratique à gérer soi-même) ou d’un hébergeur qui le permet (rarement le cas). C’est notamment pour ça que d’autres pistes ont été creusées comme je l’explique dans le papier, même si DANE reste un élément qui est dans le scope de ce que prévoit l’équipe de GPG via le protocole WKS (voir les slides)





Oui. Le soucis, c’est que j’ai pas autorité sur le DNS et mon registar ne propose pas d’enregistrement NS pour que je le fasse moi-même. J’ai que la base (A AAA TXT MX CNAME LOC NAPTR et RP) et c’est bien dommage.

Du coup chez moi j’ai un serveur DNS qui ne me sert à ….rien. A part à éviter les DNS menteurs et jouer sur le ttl au niveau local.



Pour ma part, je trouve que tout ca reste de la bidouille avec des idées/technos faites maison et les incohérences qui vont avec.



Du genre la clé doit être vérifiée par un moyen externe, mais WKD requiert une connexion https pour empêcher toute altération de la clé au moment de sa récupération. Pourquoi s’assurer que la clé est inaltérée si on doit de toute façon la vérifier ?



Du genre fabriquer la well-know URI avec Z-BASE-32(SHA1(LowerCase(LocalPart($email)))).

Y avait pas plus simple/standard en 2017 pour construire une URL ?



Même si c’est louable de travailler sur le sujet épineux du combo identité+confidentialité des internautes, la complexité du truc m’incite à croire que tout cela sera balayé par une solution clé-en-main fournie par un GAFA. Dommage…


Tu vois de la bidouille là où il est simplement question de couvrir les différents angles. Si tu mets un gilet pare-balle pour te protéger et qu’on te coupe la tête à la machette, cela ne veut pas dire que le gilet était inefficace hein ;)



Le lien chiffré permet de s’assurer d’une protection pendant le transport de la clef, pour éviter certains types d’attaques, tout en permettant ce qui est le but de WKD : une récupération rapide de la clef pour une adresse email donnée. Tu peux trouver cette solution suffisante, et t’arrêter là, c’est une possibilité. Personne ne t’oblige à faire plus.&nbsp;



Mais si tu veux t’assurer de la fiabilité de la clé via des tiers et sur le long terme, le WOT est une source d’info fiable et distribuée. C’est complémentaire, ça vise d’autres besoin. Penser que WKD est là pour assurer la confiance, c’est un peu comme ceux qui pensent que les préservatifs sont un moyen de contraception, alors qu’il s’agit d’un outil de lutte contre les MST, qui peut en partie faire office de moyen contraceptif (sans être totalement fiable, voir le cas de Ross Geller).



Pour le reste, tu oublies une dernière chose : le protocole WKS est pensé pour une intégration complète à un service de messagerie. Si ce dernier fait le taffe, l’utilisateur ne voit presque rien. Là on propose seulement un moyen de publier simplement une clef (mon Dieu il y a un ID à copier/coller) pour ceux qui veulent exploiter WKD en attendant que des services de messageries (et pourquoi pas un des GAFAM ?) commencent à l’intégrer de leur côté :)



PS : Même Signal propose un contact rapide, à compléter par une vérification visuelle des empreintes via un QR Code. On peut ne pas le faire, mais on s’expose. Comme toujours, c’est une question de choix personnels et de modèle de menace. Chacun voit midi à sa porte, l’important étant que les outils permettent de se protéger complètement lorsque c’est nécessaire.








David_L a écrit :



c’est un peu comme ceux qui pensent que les préservatifs sont un moyen de contraception, alors qu’il s’agit d’un outil de lutte contre les MST, qui peut en partie faire office de moyen contraceptif.





En fait, c’est l’INverse. La capote existait déjà au moyen-âge (boyau de porc) pour éviter les grossesses pendant que monsieur était parti à la croisade.<img data-src=" />









127.0.0.1 a écrit :



Même si c’est louable de travailler sur le sujet épineux du combo identité+confidentialité des internautes, la complexité du truc m’incite à croire que tout cela sera balayé par une solution clé-en-main fournie par un GAFA. Dommage…







Comme dit dans la niouze, il faut que les fournisseurs de services (FAI, Mail…) l’implémentent. Après, ce sera transparent pour l’utilisateur car implémenté/implémentable facilement. T’auras juste une meilleure sécurité en plus sans t’en rendre compte. Je ne vois pas ce qui te chagrine.<img data-src=" />



Raté :

3 000 ans av. J.-C. les soldats égyptiens souhaitant se protéger des maladies vénériennes utilisaient des boyaux de mouton ou des vessies de porc.



Extrait de l’article wikipedia.

Ce même article présente le préservatif à la fois comme un moyen de contraception et de protection contre les MST.



Si David a des informations sourcées (ailleurs que dans une fiction) qu’il corrige cet article. En fait, c’est logique, il n’y a pas de raison que la protection soit meilleure dans un cas que dans l’autre puisqu’elle est sensée arrêter les même fluides .



J’arrête la digression, mais, on voit que les analogies, c’est toujours casse gueule.








fred42 a écrit :



Raté :

3 000 ans av. J.-C. les soldats égyptiens souhaitant se protéger des maladies vénériennes utilisaient des boyaux de mouton ou des vessies de porc.



Extrait de l’article wikipedia.

Ce même article présente le préservatif à la fois comme un moyen de contraception et de protection contre les MST.



Si David a des informations sourcées (ailleurs que dans une fiction) qu’il corrige cet article. En fait, c’est logique, il n’y a pas de raison que la protection soit meilleure dans un cas que dans l’autre puisqu’elle est sensée arrêter les même fluides .



J’arrête la digression, mais, on voit que les analogies, c’est toujours casse gueule.





Ha, voilà ma groupie, ça faisait longtemps.

Le fait est que j’ai pas dit que la capote a été inventée au moyen-âge hein.









fred42 a écrit :



J’arrête la digression, mais, on voit que les analogies, c’est toujours casse gueule.







Rien ne vaut une bonne comparaison bagnolesque à l’ancienne pour supprimer tout malentendu. <img data-src=" />









Ricard a écrit :



Comme dit dans la niouze, il faut que les fournisseurs de services (FAI, Mail…) l’implémentent. Après, ce sera transparent pour l’utilisateur car implémenté/implémentable facilement. T’auras juste une meilleure sécurité en plus sans t’en rendre compte. Je ne vois pas ce qui te chagrine.<img data-src=" />







Je n’y crois plus. OpenPGP existe déjà depuis 20 ans !



Alors la promesse que, promis-juré, demain tout le monde va implémenter ce standard, qu’il sera intégré dans tous les outils du quotidien et que ca sera transparent… soupir…








“Promis ! on l’implémente après la sortie d’Half-Life 3” <img data-src=" />


Tu sembles quand même oublier que GPG est largement utilisé dans plein de domaines. Après, dans le cas de l’email (surtout pour le grand public) ce n’est pas courant, mais c’est un cas d’usage parmi d’autres :)



Mais c’est justement l’objectif que de partir sur un protocole simple à implémenter et simple d’usage pour l’utilisateur final. Après c’est comme tout, chacun en fera ce qu’il en voudra :)


Le préservatif n’a qu’une action physique alors que la pilule ou le sterilet agissent sur 2 à 3 points (ovulation, glaire cervicale, endomètre) qui conduiront à empêcher la nidation et donc la grossese. C’est pour cela que l’indice de Pearl du préservatif et plus élevé que celui du sterilet ou de la pilule.

https://fr.wikipedia.org/wiki/Efficacit%C3%A9_des_m%C3%A9thodes_contraceptives

https://en.wikipedia.org/wiki/Comparison_of_birth_control_methods

&nbsp;

On peut dire que le préservatif est efficace en contraception ponctuel et quand on une recherche une efficacité sur les MST grâce son effet barrière sur les “fluides”. Mais quand tu n’as pas besoin d’une protection contre les MST (partenaire unique monogame de plus 3 mois), il existe des moyens contraceptifs bien plus efficace (malheureusement la contrainte repose sur la dame).


Vous utilisez GPG dans le cadre de INpact Mediagroup ou de la Presse Libre ?



Perso, le seul endroit où j’ai remarqué une adoption de GPG c’est GitHub. Et encore, ca reste limité pour un site qui regroupe des profils techniques en matière de logiciel. Par exemple Linus Torvalds ne signe pas ses commits.



Le jour ou github (ou fb, ou google) imposera GPG a tous les comptes utilisateurs, alors là je reprendrais espoir dans l’adoption de ce standard.








127.0.0.1 a écrit :



Je n’y crois plus. OpenPGP existe déjà depuis 20 ans !



Alors la promesse que, promis-juré, demain tout le monde va implémenter ce standard, qu’il sera intégré dans tous les outils du quotidien et que ca sera transparent… soupir…





Effectivement. Mais il y a 20 ans le problème de la vie privée n’existait pas (du moins à ce niveau là)

Depuis Snowden, et globalement depuis ces dernières années (terrorisme), la problématique n’est plus la même. Beaucoup proposent leur petite soupe dans leur coin avec plus ou moins de succès. GnuPG, qu’on peut considérer comme un standard, est toujours là et ne demande qu’à être intégré. Ce qui manquait, c’est la facilité de le faire. Là ça va dans le bon sens.

Prends par exemple certaines initiatives pour la confidentialité des mails (Tutanota, Proton, CaliOpen…) ça montre le réel intérêt, du moins pour le monde pro pour l’instant. Le reste suivra.



Les “initiatives” sont surtout des services spécialisés… il ne s’agit pas d’adoption du standard par des services mainstream.



Comme dit juste avant, si demain Gmail et Outlook imposent GPG a tous les comptes utilisateurs et que FB/Twitter/G+ deviennent des Web Key Directory alors on aura fait un grand pas dans l’adoption du standard. Sinon, j’ai bien peur que ca reste un truc de nerd sécuromaniac.


Note que Facebook propose déjà un support de GPG avec chiffrement des notifications envoyées par le service et publication de la clé publique :)








127.0.0.1 a écrit :



Les “initiatives” sont surtout des services spécialisés… il ne s’agit pas d’adoption du standard par des services mainstream.



Comme dit juste avant, si demain Gmail et Outlook imposent GPG a tous les comptes utilisateurs et que FB/Twitter/G+ deviennent des Web Key Directory alors on aura fait un grand pas dans l’adoption du standard. Sinon, j’ai bien peur que ca reste un truc de nerd sécuromaniac.





Ben, c’est à ça que sert cette initiative. <img data-src=" />



Oui, Facebook gère également l’Esperanto. Mais je n’ai pas vu une adoption massive de cette langue depuis ce support… <img data-src=" />


Je me rappelle plus bien de la gestion des versions : GuPG 2.1.23, c’est celle avec ou sans porte dérobée ?




Pour le modèle de confiance, c’est TOFU



Bravo, maintenant j’ai faim…


Avec ce nom, ça doit être avec porte dérobée. Un logiciel Gnu, au contraire, tu as les sources, la porte dérobée est plus difficile à cacher.








fred42 a écrit :



Avec ce nom, ça doit être avec porte dérobée. Un logiciel Gnu, au contraire, tu as les sources, la porte dérobée est plus difficile à cacher.





Ça serait bien. Faut pas s’attendre non plus à un commit by FBI/NSA <img data-src=" />

http://www.cnis-mag.com/quand-le-fbi-fait-dans-l%E2%80%99opensource.html

https://www.nextinpact.com/archive/60876-openbsd-backdoors-fbi-gregory-perry-theo-de-raadt.htm

<img data-src=" />



Ont-il ajouté une fonction pour chiffrer un fichier directement avec une clé publique sans l’ajouter dans un trousseau ? Un peu à la manière du chiffrement symétrique proposé avec cette commande :



&nbsp;gpg2 –output CHEMIN_DESTINATION/NOM_FICHIER.gpg –symmetric NOM_FICHIER_SOURCE



Ce serai super utile pour un usage avec des livecd ou simplement pour ne pas laisser de trace sur la machine que l’on utilise (clé privé sur une clé USB chiffré).


Le principe du symétrique, c’est qu’il n’y a pas de clé, du coup c’est un peu logique qu’elle ne soit pas ajoutée à un trousseau. Après rien ne t’empêche de supprimer la clef publique ensuite ou d’utiliser un trousseau temporaire avec –primary-keyring, mais j’ai du mal à comprendre quel est le souci dans le fait de stocker une clef publique pour assurer le chiffrement d’un fichier.


Non, je ne pense pas qu’il y ait (enfin) un mode d’utilisation sans fichier keyring.



Par contre, on peut facilement créer/travailler avec un keyring temporaire (option –primary-keyring, ou meme –homedir).

Il faudra juste penser à supprimer le fichier keyring à la fin.



Edit: grillé par le chef. Ca m’apprendra a pas rafraichir mes onglets. <img data-src=" />








David_L a écrit :







127.0.0.1 a écrit :



Merci de vos réponses (dit donc vous êtes chauds pour répondre à 23h passé xD. Au taquet les gars !).

Dommage qu’une telle fonction ne soit pas implémenté. L’intérêt principal que je portait à chiffrer un fichier avec une clé publique sans l’importer est la simplicité. Ça permettrai de ce servir banalement de GPG sans avoir à sortir la doc à chaque fois. Je travail sur des systèmes squashfs qui boot en PXE intégralement en RAM donc chaque action est à refaire à chaque démarrage. Réimporter une clé pour chiffrer un fichier à chaque fois est d’une lourdeur inutile.

Un jour peu être <img data-src=" />.



Du coup je comprends pas, tu veux faire de l’asymétrique mais sans clé à importer ? (Je ne vois pas le rapport avec la doc au passage).&nbsp;








David_L a écrit :



Du coup je comprends pas, tu veux faire de l’asymétrique mais sans clé à importer ?



&nbsp;Oui. Avec une commande de type “gpg2 –output CHEMIN_DESTINATION/NOM_FICHIER.gpg –asymmetric CHEMIN_DE_LA_CLE_PUBLIQUE NOM_FICHIER_SOURCE”.

&nbsp;

Pour la doc c’était simplement pour dire que de tête, importer une clé dans un trousseau je sais pas faire. Obliger de sortir l’anti sèche pour le faire.



Mais en fait ce que tu veux faire est déjà possible, sauf que tu n’indiques pas l’emplacement d’une clef publique mais d’un trousseau (ce qui revient fondamentalement au même puisque c’est juste un emplacement de fichier)