Seule l’option KDF-DO nécessite GnuPG 2.2.6 (sortie en avril 2018). L’option factory-reset ou la prise en charge des courbes elliptiques (y compris la courbe 25519) font partie des fonctionnalités introduites dans la branche de développement GnuPG 2.1 (par exemple, version 2.1.1 en décembre 2014 pour factory-reset) et à ce titre sont présentes depuis le début de la branche 2.2 sortie en août dernier.
En fait, mon commentaire concernait l'utilisation des options présentées avec Gnuk.
S'il est facile, avec GnuPG 2.2.x de choisir facilement la génération de clefs RSA ou EC sur les clefs Gnuk, ce n'est pas le cas avec GnuPG 2.1.x (nécessité de forcer au préalable la génération de clefs elliptiques comme expliqué ici https://www.nitrokey.com/news/2017/nitrokey-start-supports-elliptic-curves-ecc)
De plus, GPG 2.1.11 (ex LinuxMint 18 LTS/Debian Stretch, Ubuntu 17.10 LTS maintenu -> 2022) ne connaît pas les clefs x25519 (chiffrement).
Une commande gpg2 --card-status sur une clef GNUK contenant des clefs Curve 25519 donne :
"Key attributes : ed25519 (null) ed25519"
au lieu de "Key attributes ...: ed25519 x25519 ed25519" avec GnuPG 2.2.x
Pas seulement. En fait, d’après Bernstein and Lange (2016) (full disclosure : Daniel J. Bernstein est l’un des principaux auteurs derrière la courbe 25519), les soupçons de manipulation de la part du NIST ne seraient même pas le véritable problème des courbes du NIST, qui de par leur conception sont intrinsèquement beaucoup plus susceptibles à toutes sortes d’attaques par canaux cachés (ce qui à mon humble avis reflète simplement le fait que ces courbes ont été conçues il y a une vingtaine d’années, au tout début de la cryptographie ECC — la courbe 25519 est « meilleure » non pas parce qu’elle n’a pas été manipulée, mais parce qu’elle bénéficie des progrès des quinze dernières années de recherche dans le domaine)
Je comprends parfaitement votre position de ne parler que de la version récente et maintenue de GnuPG (2.2.x) mais ayant été confronté au problème GnuPG 2.1.x par défaut sur ma distribution, je pense qu'il est préférable d'insister sur le fait que l'article n'est valable qu'à partir de GnuPG 2.2.x minimum,pour toutes personnes commençant à s'intéresser au sujet.
[^] # Re: Excellent article. Quelques précisions et ajouts
Posté par yokosano . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 6.
Bonjour,
En fait, mon commentaire concernait l'utilisation des options présentées avec Gnuk.
S'il est facile, avec GnuPG 2.2.x de choisir facilement la génération de clefs RSA ou EC sur les clefs Gnuk, ce n'est pas le cas avec GnuPG 2.1.x (nécessité de forcer au préalable la génération de clefs elliptiques comme expliqué ici https://www.nitrokey.com/news/2017/nitrokey-start-supports-elliptic-curves-ecc)
De plus, GPG 2.1.11 (ex LinuxMint 18 LTS/Debian Stretch, Ubuntu 17.10 LTS maintenu -> 2022) ne connaît pas les clefs x25519 (chiffrement).
Une commande gpg2 --card-status sur une clef GNUK contenant des clefs Curve 25519 donne :
Mon observation portait sur le fait que la courbe Curve25519 fait l'objet de choix plutôt expliqués et documentés, ce qui n'est pas le cas des courbes du NIST comme des courbes ANSSI (https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000024668816), pourtant assez récentes : 2011.
Courbes dont le choix des paramètres est "obscure" et laisse à penser qu'il peut y avoir "manipulation" comme expliqué ici §4.1.1 : https://connect.ed-diamond.com/MISC/MISCHS-013/Standardisation-des-courbes-elliptiques-a-qui-faire-confiance
Je comprends parfaitement votre position de ne parler que de la version récente et maintenue de GnuPG (2.2.x) mais ayant été confronté au problème GnuPG 2.1.x par défaut sur ma distribution, je pense qu'il est préférable d'insister sur le fait que l'article n'est valable qu'à partir de GnuPG 2.2.x minimum,pour toutes personnes commençant à s'intéresser au sujet.
Bien cordialement