Re: gpg2 --card-status

C’est du même acabit. J’avais d’ailleurs essayé de le faire comprendre à son auteur à l’époque...

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

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 :

# Limite les algorithmes utilisés
personal-cipher-preferences AES256
personal-digest-preferences SHA512

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 des personal-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-preferences et 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.

cipher-algo AES256
digest-algo SHA512

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 :

1 Utiliser la dernière version de GnuPG (2.2.x ; pas de GnuPG 1.4, 2.0, ou 2.1) ;

2 Utiliser les réglages par défaut ; n’ajoutez une ligne dans votre gpg.conf que 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.