Si, mais c’est une addition récente au standard (RFC 6637).
GnuPG permet d’utiliser les courbes elliptiques depuis la version 2.1.0, mais pas par défaut. Il faut utiliser le « mode expert » (option --expert) pour se voir offrir la possibilité de générer des clefs ECC.
Pourquoi ? Est-ce uniquement à cause de l'historique ?
Je crois que l’introduction des courbes elliptiques a été freinée par des histoires de brevets logiciels, mais je ne connais pas les détails.
Si elles ne sont pas utilisées par défaut dans GnuPG aujourd’hui, c’est surtout parce que rare sont les implémentations d’OpenPGP qui les prennent en charge. Générer des clefs ECC par défaut signifierait que les utilisateurs qui acceptent les réglages par défaut se retrouveraient avec des clefs inutilisables pour la plupart des gens (tous ceux qui utilisent des implémentations sans support d’ECC, en particulier tous les utilisateurs de GnuPG 1.4/2.0).
Quels sont les différences d'un point de vue sécurité entre ces deux manière de générer des clés publiques/privées ?
Ce ne sont pas des « manières de générer des clefs », ce sont des types de clefs complètement différents, basés sur des problèmes mathématiques distincts.
Je ne suis absolument pas qualifié pour discuter des différences fondamentales entre la cryptographie « non-ECC » (tous les algorithmes classiques comme RSA, ElGamal, DSA) et la cryptographie ECC (ECDH, ECDSA). Tout ce que je sais, c’est que la plupart des cryptographes admettent que les clefs ECC fournissent une sécurité au moins équivalente à celle de RSA pour des tailles de clefs très inférieures (une clef ECC typique fait 256 bits, et c’est déjà considéré comme fournissant une sécurité supérieure à celle fournie par une clef RSA de 2048 bits).
(Ah oui, et je sais aussi que je n’ai que très modérément confiance dans la plupart des courbes elliptiques dont les paramètres ont été judicieusement choisis — mais judicieusement pour qui ? — sur des critères non-spécifiés...)
Si libsodium génére des clefs ECC, la génération peut être plus rapide déjà parce que les clefs sont plus petites. Mais surtout, il est probable que cette bibliothèque utilise une méthode de génération de nombres aléatoires différente.
GnuPG est assez lent à générer des clefs d’une part parce qu’il est assez gourmad en entropie (probablement trop, ce qui a justement fait l’objet d’une discussion récente sur gnupg-devel), et d’autre part parce, du moins sous GNU/Linux, il obtient son entropie depuis le pool bloquant du système (/dev/random). Beaucoup d’autres implémentations puisent à l’inverse dans le pool non-bloquant (/dev/urandom) — pas forcément à tort d’ailleurs.
[^] # Re: OpenPGP, libsodium...
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 4.
Si, mais c’est une addition récente au standard (RFC 6637).
GnuPG permet d’utiliser les courbes elliptiques depuis la version 2.1.0, mais pas par défaut. Il faut utiliser le « mode expert » (option
--expert) pour se voir offrir la possibilité de générer des clefs ECC.Je crois que l’introduction des courbes elliptiques a été freinée par des histoires de brevets logiciels, mais je ne connais pas les détails.
Si elles ne sont pas utilisées par défaut dans GnuPG aujourd’hui, c’est surtout parce que rare sont les implémentations d’OpenPGP qui les prennent en charge. Générer des clefs ECC par défaut signifierait que les utilisateurs qui acceptent les réglages par défaut se retrouveraient avec des clefs inutilisables pour la plupart des gens (tous ceux qui utilisent des implémentations sans support d’ECC, en particulier tous les utilisateurs de GnuPG 1.4/2.0).
Ce ne sont pas des « manières de générer des clefs », ce sont des types de clefs complètement différents, basés sur des problèmes mathématiques distincts.
Je ne suis absolument pas qualifié pour discuter des différences fondamentales entre la cryptographie « non-ECC » (tous les algorithmes classiques comme RSA, ElGamal, DSA) et la cryptographie ECC (ECDH, ECDSA). Tout ce que je sais, c’est que la plupart des cryptographes admettent que les clefs ECC fournissent une sécurité au moins équivalente à celle de RSA pour des tailles de clefs très inférieures (une clef ECC typique fait 256 bits, et c’est déjà considéré comme fournissant une sécurité supérieure à celle fournie par une clef RSA de 2048 bits).
(Ah oui, et je sais aussi que je n’ai que très modérément confiance dans la plupart des courbes elliptiques dont les paramètres ont été judicieusement choisis — mais judicieusement pour qui ? — sur des critères non-spécifiés...)
Si libsodium génére des clefs ECC, la génération peut être plus rapide déjà parce que les clefs sont plus petites. Mais surtout, il est probable que cette bibliothèque utilise une méthode de génération de nombres aléatoires différente.
GnuPG est assez lent à générer des clefs d’une part parce qu’il est assez gourmad en entropie (probablement trop, ce qui a justement fait l’objet d’une discussion récente sur gnupg-devel), et d’autre part parce, du moins sous GNU/Linux, il obtient son entropie depuis le pool bloquant du système (
/dev/random). Beaucoup d’autres implémentations puisent à l’inverse dans le pool non-bloquant (/dev/urandom) — pas forcément à tort d’ailleurs.