web-dev-qa-db-fra.com

ECC dans (Open) PGP

Comment va le support de ECC (Cryptographie à courbe elliptique) dans (Open) PGP jusqu'à présent? Il semble que GnuPG (Le GNU Privacy Guard) n'a pas d'implémentation officielle - mais j'ai trouvé le projet gnupg-ecc ( GnuPG compatible ECC par RFC 6637) sur Google Code:

Ce projet a donné vie à la prise en charge de la cryptographie Elliptic Curve dans OpenPGP en tant que fonctionnalité pour l'utilisateur final. Les utilisateurs peuvent simplement sélectionner une option de génération de clé ECC dans

gpg2 --gen-key

puis utilisez la clé publique générée comme ils utiliseraient normalement toute autre clé publique, comme indiqué ici .

Je sais que Symantec prend en charge ECC. Y a-t-il des raisons de ne pas utiliser ECC?

[~ # ~] modifier [~ # ~]

J'ai fait plus de recherches et découvert qu'ECC a trouvé son chemin vers la ligne principale de gnupg il y a longtemps, mais uniquement dans la version développeur :

$ gpg2 --expert --gen-key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
    (7) DSA (set your own capabilities)
    (8) RSA (set your own capabilities)
    (9) ECDSA and ECDH
   (10) ECDSA (sign only)
   (11) ECDSA (set your own capabilities)
Your selection?`
pgpecc
24
esskar

Je vois deux raisons principales pour lesquelles vous pourriez ne pas vouloir utiliser ECC :

Raison pratique: la communication implique nécessairement deux parties, l'expéditeur et le destinataire. ECC ne peut être utilisé que si l'expéditeur et le destinataire le prennent en charge. Comme vous l'avez remarqué, les implémentations existantes et déployées ne sont pas encore nécessairement à la hauteur; si vous utilisez une clé publique ECC, les utilisateurs peuvent vous envoyer des messages chiffrés avec cette clé ou vérifier vos signatures avec cette clé, uniquement si leur implémentation OpenPGP inclut le code correspondant.

Donc, votre choix de ECC ou non ECC dépend de si vous voulez maximiser l'interopérabilité ou préférez être un "early adoptant" (bien que dans le cas d'ECC, les adopteurs vraiment précoces soient déjà là; ECC devient courant).

Raison morale: mathématiquement, nous n'avons aucune preuve qu'aucun des algorithmes cryptographiques que nous utilisons n'est vraiment robuste contre les attaques. Nous ne savons même pas s'il est mathématiquement possible d'être robuste contre les attaques. À l'heure actuelle, la seule méthode dont nous disposons pour évaluer la force d'un algorithme cryptographique est de le définir, puis de laisser beaucoup de cryptographes travailler dessus pendant quelques années. Si aucune de ces personnes intelligentes n'a trouvé quelque chose de mal avec l'algorithme, alors vous pouvez savoir que si l'algorithme est faible, alors, au moins, il n'est pas évidemment faible.

Les courbes elliptiques ont été proposées comme objets adaptés à la cryptographie en 1985 (par Koblitz et Miller, indépendamment). Les mathématiques des courbes elliptiques ont été étudiées pendant environ 40 ans auparavant. Ainsi, ECC peut arborer environ 70 ans d'exposition, dont 30 dans un cadre définitivement cryptographique. C'est pas mal.

factorisation entière , sur laquelle se fonde le RSA, peut revendiquer 35 ans d'exposition cryptographique (RSA a été proposé en 1978), et plus qu'une coqueluche 2500 ans pour le sous-jacent mathématiques. On peut donc affirmer que la sécurité du RSA est "plus comprise" que celle des courbes elliptiques.

Personnellement, je pense que ECC est suffisamment mature pour être déployé, et comme ECC est très à la mode, les implémentations deviennent monnaie courante et nous pouvons nous attendre à ce que GnuPG s'aligne rapidement. Ainsi, ma recommandation est la suivante: ECC est très bien, tant que vous êtes prêt à rencontrer des problèmes d'interopérabilité pendant quelques années.

(Un point noir du déploiement ECC est qu'il y a très peu d'implémentations ECC "génériques"; la plupart des implémentations sont spécifiques à un ensemble restreint de courbes prises en charge, souvent limitées aux deux courbes NIST P-256 et P-384. Le choix de la courbe car votre clé a donc un impact non négligeable sur l'interopérabilité. Cependant, le P-256 est très bien pour la sécurité, vous pouvez donc l'utiliser et ne plus vous inquiéter.)

25
Thomas Pornin

Actuellement, ECC est pris en charge dans GnuPG 2.1 beta. Vous pouvez le compiler à partir de la source et constater par vous-même que les courbes suivantes sont prises en charge:

nistp256 nistp384 nistp521 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 secp256k1

9
Adrian

dans GPG, pour des raisons de sécurité, on resterait à l'écart du brainpool et des nist courbes. Les courbes edDSA, montgomery et edwards sont fines. ed25519 est heureusement déployé sans sous-buste pour l'instant.

Bien que ce soit juste pour la signature/certification/authentification. Le cryptage suivra.

les listes de diffusion sur ietf.org sont d'excellents endroits pour commencer, ainsi que pour vérifier cryp.to.

Utiliser ECC avec une implémentation folie est pire que d'utiliser même RSA.

6
Njomsky