Après de petites évolutions de sa branche 2.3, GPG4Win s'apprête à publier une nouvelle version majeure : la 3.0. Celle-ci doit accompagner GPG 2.2 afin d'en faciliter l'usage sous Windows, notamment au sein d'Outlook.
Comme nous l'avons évoqué récemment, les développeurs de l'outil de chiffrement GnuPG (GPG) viennent de livrer une mouture 2.1.23 qui change de nombreux éléments. Surtout, il s'agit d'une release candidate pour la future branche 2.2 qui deviendra d'ici quelques semaines la nouvelle branche stable de l'application.
Cette étape importante en entraîne d'autres dans l'écosystème de GPG. Et c'est ainsi un autre outil d'importance qui s'apprête à franchir une étape majeure de son évolution : GPG4Win.
La lente évolution de GPG4Win
Actuellement disponible en version 2.3.4, sortie en juillet (basée sur la branche 2.0 de GPG), le pack d'applications pour Windows prépare depuis des mois ce changement. Pour rappel, en complément de GPG il permet d'installer simplement le gestionnaire de clés Kleopatra, mais aussi de l'extension GpgEX, de Gnu Privacy Assistant (GPA) ou encore de GpgOL, un plugin destiné à apporter le support du chiffrement sous Outlook.
Sa dernière version majeure, la 2.3.0 datait de fin 2015. Elle permettait le support de l'accélération matérielle à travers AES-NI, des formats PGP/MIME et S/MIME mails ou encore d'Outlook 2016, puis de sa version 64 bits à travers la 2.3.1 sortie quelques mois plus tard. Autant dire que son équipe était jusque-là assez avare en nouveautés.
Une ère de renouveau, liée à l'évolution de GPG
Mais depuis quelques mois, et les objectifs de simplification d'EasyGpg 2016, tout s'est accéléré. La version 3.0 a ainsi été publiée en version bêta, permettant à ceux qui le désiraient d'avoir accès à la branche moderne de GPG (actuellement la 2.1) et de commencer à remplir les objectifs fixés.
Peu à peu, on a donc pu voir les outils intégrés s'améliorer. C'est notamment le cas de Kleopatra, même si toutes les pistes évoquées pour ce dernier n'ont pas été suivies, notamment le Pad.
En fin de semaine dernière, peu après la mise en ligne de GPG 2.1.23 qui active le support par défaut des Web Key Directory / Service, une nouvelle version d'importance a été mise en ligne : la beta 287. Celle-ci est en effet une release candidate, annonçant la proximité de la sortie de la version finale (bien que la traduction soit encore incomplète).
Après WKS/WKD, TOFU est en approche
Outre les retouches apportées à l'interface de Kleopatra (KDE Framework 5) et de GpgOL afin de simplifier leur utilisation, on trouve de nombreuses améliorations et autres nouveautés.
Ainsi, il est question du support des emails en HTML et des pièces jointes sous Outlook, des clés ECC, du chiffrement d'un dossier complet, des clés de sécurité (voir notre analyse), de l'export sous forme de Paper key, de l'ouverture automatique des fichiers chiffrés/signés ou encore du chiffrement symétrique (qui peut être utilisé conjointement à un chiffrement classique). On notera aussi que les serveurs de clés SKS sont désormais ceux utilisés par défaut.
Mais c'est surtout du côté du support du nouveau modèle de confiance TOFU (voir notre analyse) qu'il faut désormais regarder. Bien qu'il ne soit pas encore activé par défaut (il peut l'être dans les paramètres de Kleopatra ou en ajoutant trust-model tofu+pgp à gpg.conf), il s'agit de la prochaine grande étape de l'évolution de GPG(4Win).
Outre d'éventuels correctifs qui pourront être mis en place d'ici la fin de l'année, la mouture 3.1 de GPG4Win est pour sa part attendue pour le premier trimestre de l'année prochaine. La liste des fonctionnalités n'est pas encore définie, mais il est d'ores et déjà prévu de retirer le support d'Outlook 2003/2007, aussi abandonné par Microsoft dès la fin de l'année.
Commentaires (5)
Malheureusement, tout ca reste encore trop complexe pour démocratiser GPG.
Ces outils visent une infime partie des internautes, ceux qui ont à la fois:
Et comme si ca ne suffisait pas, le destinataire doit lui aussi être dans le même cas.
Ca va être de plus en plus dur pour GPG de percer face aux messageries/services web qui vendent du “chiffrement” intégré à leurs applis.
Elles reposent aussi sur un chiffrement asymétrique et un échange de clés (et donc le besoin d’utiliser la même App de l’autre côté). C’est planqué, donc tu ne sais rien de ce qui est mis en place et de ce que tu as comme sécurité effective, c’est la différence (genre vérifier ses clefs sous Signal).
Après TOFU / WKS-WKD sont justement là pour reproduire une expérience similaire de ne pas avoir à récupérer les clefs ou à les vérifier sur un premier contact. Mais si tu veux t’assurer que tout est ok, il faudra toujours comprendre un minimum ce que tu fais. (par contre générer une clef et l’utiliser rien que pour signer ses emails c’est à la portée du premier venu)
par contre générer une clef et l’utiliser rien que pour signer ses emails c’est à la portée du premier venu
Avec un chance sur deux que le “premier venu” colle sa clé privée dans l’espace publique (voire dans sa signature de message).
Faut tout de même le faire, m’enfin c’est comme la 2FA par SMS qui affiche le code sur ton portable en écran verrouilé ou le fait de coller un mot de passe générique dans le premier formulaire venu. On empêchera jamais l’utilisateur d’être bête
" />
D’où le besoin d’expliquer les choses, parce que les solutions “ne vous occupez de rien on s’occupe de tout” simplifient sans éduquer, alors que sur le fond sur ces questions on a surtout besoin d’expliquer les choses aux utilisateurs (sans forcément leur prendre la tête, on est d’accord).
Perso, je me bat souvent pour expliquer le principe clé publique/clé privée, faute d’analogie compréhensible. Et pour ceux qui arriveraient à comprendre le principe, je les perd généralement quand les outils (gpg, openssl…) demandent un mot-de-passe.
" />