Bonjour à tous,
Ayant fait l'acquisition d'une Yubikey, j'ai crée à partir de ma Debian, sur mon portable, ma clé et mes sous-clés en suivant, entre autre, ce tuto.
Je suis bien comme dans l'exemple suivant, tout fonctionne bien :
> wilson@spaceship:~$ gpg2 --list-secret-keys
/home/wilson/.gnupg/pubring.gpg
--------------------------------
sec# rsa4096/1A8132B1 2017-10-05 [C] [expires: 2018-10-05]
uid [ultimate] Wilson Eleven <wilson.eleven@labs.com>
ssb> rsa4096/B73A9C79 2017-10-05 [E] [expires: 2018-10-05]
ssb> rsa4096/9CC8B2FB 2017-10-05 [S] [expires: 2018-10-05]
ssb> rsa4096/8047B454 2017-10-05 [A] [expires: 2018-10-05]
J'utilise aussi Windaube sur mon fixe et j'ai importé mes clés publiques puis mes sous-clés privés. J'ai bien le "sec#" mais, forcément, pas le ">" sur mes sous-clés.
Du coup, je ne sais pas quelles commandes saisir pour indiquer à GPG que mes clés privés se trouvent sur ma Yubikey sans réimporter localement et ré-exporter. Savez-vous comment faire ?
Merci par avance de votre aide.
# gpg2 --card-status
Posté par gouttegd (site web personnel) . Évalué à 2. Dernière modification le 07 avril 2020 à 10:45.
Il suffit d’utiliser la commande
gpg2 --card-statusalors que la Yubikey est insérée. L’agent GnuPG va automatiquement créer les “stub keys” pointant vers les clefs privées sur la Yubikey.Aparté :
Sigh… Encore un « tuto » prétendant créer la « clef parfaite », rempli de conseils inutiles, obsolètes, voire même dangereux…
[^] # Re: gpg2 --card-status
Posté par NeoX . Évalué à 2.
en meme temps le tutoriel date de 2017
en matière de Secu, ca fait une éternité… ;)
[^] # Re: gpg2 --card-status
Posté par gouttegd (site web personnel) . Évalué à 2.
La plupart des « conseils » donnés étaient déjà obsolètes/inutiles/dangereux en 2017…
[^] # Re: gpg2 --card-status
Posté par eric gerbier (site web personnel) . Évalué à 1.
qu'est-ce que vous pensez du tuto de nexinpact : https://www.nextinpact.com/news/102685-gpg-comment-creer-paire-clefs-presque-parfaite.htm ?
[^] # Re: gpg2 --card-status
Posté par gouttegd (site web personnel) . Évalué à 10.
C’est du même acabit. J’avais d’ailleurs essayé de le faire comprendre à son auteur à l’époque…
C’est tout simplement faux. Ce ne serait pas très grave si les conseils donnés pour prétendument « optimiser » les paramètres de GnuPG étaient inoffensifs, mais ce n’est pas le cas : certains affaiblissent la sécurité.
Juste un exemple :
Je mets ma main à couper que tous ceux qui recopient bêtement ces lignes dans leur
gpg.conf, pensant améliorer la sécurité de leur communication en forçant l’utilisation de AES256 et SHA512, n’ont pas la moindre idée de ce qu’ils font réellement.Alors, pour information : ces deux lignes augmentent considérablement le risque de voir vos messages chiffrés avec 3DES et vos signatures condensées avec SHA1 (les deux algorithmes les plus « faibles » actuellement disponibles dans OpenPGP).
3DES et SHA1 sont encore aujourd’hui obligatoires dans OpenPGP — la prochaine version du standard changera ça, mais on n’en est pas encore là malheureusement et pour l’instant les implémentations se doivent de toujours les supporter. Même si vous ne mentionnez que AES256 dans la liste
personal-cipher-preferences, GnuPG rajoutera tacitement 3DES en fin de liste (similairement, SHA1 sera silencieusement ajouté à la liste despersonal-digest-preferences). Pourquoi ? PParce que la communication, ça se fait à deux (au moins) et vous n’avez personnellement aucun contrôle sur les algorithmes qui sont supportés par l’implémentation de votre correspondant. 3DES et SHA1 sont les deux seuls algorithmes dont le support est garanti par le standard (encore une fois ça changera avec la prochaine version du standard, mais pour l’instant on est encore au RFC4880), donc avoir ces algorithmes dans la liste assure que quelques soient les autres algorithmes dans la liste, la liste contiendra toujours au moins un algorithme supporté par le logiciel d’en face.Maintenant, imaginons que le logiciel de votre correspondant supporte AES128 mais pas AES256 (ou que le logiciels supporte ces algos mais que votre correspondant, qui a des opinions fortes en matière d’algorithmes de cryptographie, a choisi de les désactiver). Que va-t-il se passer ? GnuPG doit choisir un algorithme présent à la fois dans la liste
personal-cipher-preferenceset dans la liste de ceux supportés par le correspondant (liste qu’il trouve dans sa clef publique). Il n’a pas le choix, le seul algorithme commun aux deux listes est 3DES.Autrement dit, en voulant bêtement forcer GnuPG à utiliser l’algorithme que vous pensez être le plus « fort », vous réduisez considérablement sa marge de manœuuvre et le contraignez en fin de compte à se rabattre sur l’algorithme le plus « faible ».
Alors bon, peut-être que c’est ce que vous voulez, hein. Mais qu’il me soit permis de questionner le bien-fondé de cette « optimisation », et les compétences de ceux qui les recommandent.
Ah ben là, je n’ai plus aucun doute sur les compétences de l’auteur. Ces deux lignes ont pour effet de rendre les deux lignes précédentes complètement inutiles. Désormais, GnuPG va complètement ignorer le mécanisme des préférences et systématiquement utiliser les deux algorithmes mentionnés. Outre le problème évident d’interopérabilité que ça pose (et qui mériterait au minimum d’être expliqué dans l’article, histoire que les gens recopiant ça comprennent les implications), ça démontre que l’auteur ne comprend pas comment GnuPG sélectionne les algorithmes à utiliser. À quoi bon perdre du temps à restreindre la liste des algorithmes préférés si c’est pour dire à GnuPG juste après « oh et puis non en fait on s’en fout des préférences, utilise ça et point barre » ?
J’adore aussi le fait que le tuto recommande de mettre la clef principale secrète hors-ligne (et donne les instructions en ce sens), sans jamais discuter du bien-fondé de la manœuvre (c’est pas forcément une mauvaise idée et d’ailleurs je le fais moi-même, mais il y a des avantages et inconvénients qui mériteraient d’être expliqués avant de donner ça comme une bonne pratique à suivre) et surtout sans jamais donner les instructions nécessaires pour utiliser la clef principale mise hors-ligne (alors que c’est quand même une difficulté majeure). le jour où la personne qui a naïvement suivi ce tuto voudra certifier une clef ou modifier son propre trousseau (ce qui nécessite la clef principale), ça va lui faire tout drôle…
Pour info, mon propre tuto pour utiliser GnuPG, en deux étapes :
① Utiliser la dernière version de GnuPG (2.2.x ; pas de GnuPG 1.4, 2.0, ou 2.1) ;
② Utiliser les réglages par défaut ; n’ajoutez une ligne dans votre
gpg.confque si vous êtes capables d’expliquer en long en large et en travers ce que fait cette ligne et pourquoi vous pensez en avoir besoin.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: gpg2 --card-status
Posté par Tenshiphe . Évalué à 1.
Bonsoir,
Merci pour vos retours, c'est pour le moins instructifs.
Vu que je suis sous windows, il s'agit de "gpg" sans le "2" mais je ne pense pas que cela ai un impact. La version de GPG est la 2.2.19. Résultat : pas de changement… Ma question peut sembler naïve mais cette commande n'est-elle pas juste de l'affichage ?
L'autre tuto sur lequel je me suis basé est celui-là mais je pense que c'est du même acabit non ?
Vous aurez aisément compris que je débute avec l'usage des clés PGP. J'ai pris ces tutos car ils sont en français et me permettent de manipuler la ligne de commande afin de mieux comprendre les mécanismes de base. Je peut lire et appliquer les tutos en anglais mais pour la compréhension de ce que l'on fait, c'est forcément moins évident. Je n'ai pas trouvé de tuto ou site plus explicite sans sortir l'aspirine. Si vous en connaissez un, je suis preneur. Je suis prêt à tout refaire, j'ai du temps avec le confinement ;)
Et merci pour votre temps !
[^] # Re: gpg2 --card-status
Posté par gouttegd (site web personnel) . Évalué à 3.
Non en effet. J’ignorais que GnuPG 2 était installé sous le nom
gpgsur les systèmes Windows, c’est tout.C’est en effet essentiellement une fonction d’affichage, mais elle a des effets de bord, dont celui d’informer l’agent GnuPG de la présence des clefs sur la carte (ou la Yubikey).
Mais dans votre cas, la commande n’a pas d’effets parce que vous avez importé non seulement vos clefs publiques mais aussi vos sous-clefs privées. Du coup, l’agent GnuPG a déjà connaissance des sous-clefs privées, et il ne tient pas compte de ce qu’il trouve sur la Yubikey.
Ici, il aurait suffit d’importer les clefs publiques uniquement, puis d’insérer la Yubikey et de lancer la commande
gpg --card-status. Là ça aurait fonctionné du premier coup.Il faut donc revenir en arrière et supprimer les sous-clefs privées que vous avez importés:
(Attention à ne pas oublier le ! après l’identifiant de clef.)
Après ça, un
gpg --list-secret-keysdevrait indiquer ssb# devant chaque sous-clef, confirmant l’absence des sous-clefs privés. On peut donc maintenant ré-insérer la Yubikey et relancer la commandegpg --card-status, qui cette fois-ci devrait avoir l’effet de bord escompté.Il est pire… Recommander une clef maître de 8192 bits, bon sang… Je ne suis même pas allé plus loin que ça, l’auteur ne sait clairement pas de quoi il parle.
[^] # Re: gpg2 --card-status
Posté par Tenshiphe . Évalué à 2.
Bonsoir,
En bref, ça fonctionne !
En plus verbeux, j'ai effectivement essayé d'importer mes sous-clés privés et ne voyant pas de changement, j'ai voulu les supprimer. J'ai seulement saisi la commande
gpg --delete-secret-keyssans indiquer les identifiants des clés… Du coup, cela n'a rien supprimé du tout et la commandegpg --card-statusn'a pas abouti. Même si je l'avais indiqué je n'aurais pas mis le!et j'aurais supprimé toute ma sous-clé si j'ai bien compris.Si quelqu'un lit un jour ce post pour une raison similaire à la mienne, je l'invite à prendre connaissance de la page de manuel indiqué par la commande
gpg --help. Ca peut paraitre évident mais ça va mieux en le disant. Elle est en anglais mais elle m'a permis de faire le lien entre les indications de la communauté Linuxfr et les erreurs de syntaxe que j'ai fais…Merci pour votre aide précieuse !
[^] # Re: gpg2 --card-status
Posté par arnauld . Évalué à 5.
Ce serait sympa de créer un tuto à jour et compréhensible alors. Moi aussi quand j'ai créé mes clés j'ai galéré pour trouver un tuto bien expliqué.
arnauld
[^] # Re: gpg2 --card-status
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Je crois que dans Tails, on est plutôt satisfait de https://riseup.net/fr/security/message-security/openpgp/gpg-best-practices
Mais je ne vois pas d'information quant aux dates de publication, édition, etc., ce qui me semble un peu dommage.
Debian Consultant @ DEBAMAX
[^] # Re: gpg2 --card-status
Posté par arnauld . Évalué à 1.
Merci du lien.
arnauld
[^] # Re: gpg2 --card-status
Posté par gouttegd (site web personnel) . Évalué à 2.
L’invitation à « vérifier que vous avec une clef OpenPGPv4 » ou à vérifier que les auto-signatures n’utilisent pas MD5 suggère fortement que ce document a une origine très ancienne…
Et la recommandation « vous devriez utiliser un agent » (en commentaire pour expliquer la présence de l’option
use-agentdans le fichier de configuration qu’ils proposent) indique que le document est écrit pour GnuPG 1.x (un tel conseil n’a aucun sens pour GnuPG 2.x, qui utilise un agent que vous le vouliez ou non), ce qui est un énorme red flag.Fun fact : aujourd’hui (et depuis pas mal de temps déjà) aucune des options figurant dans ce fichier de configuration n’est utile. Tous les comportements voulus sont déjà actifs par défaut.
La seule option significative est
cert-digest-algo SHA-512: elle remplace l’algorithme de condensation utilisé pour les certifications, qui est SHA-256 par défaut, par SHA-512. Et ce changement n’est pas nécessairement une bonne idée. SHA-512 est moins répandu dans les implémentations que SHA-256, donc certifier avec SHA-512 fait courir le risque de se retrouver avec des certifications qui ne seront pas utilisables par tout le monde.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.