Meilleur algorithme de cryptage et de signature pour GnuPG: RSA / RSA ou DSA / Elgamal? [fermé]


46

J'ai trouvé cette question relativement ancienne pour savoir si RSA ou DSA est l'algorithme préféré pour la signature et le cryptage avec GnuPG.

Lors de l'utilisation gpg --gen-key, les deux choix pertinents sont "RSA et RSA" ou "DSA et Elgamal". Ce qui est mieux? Quels sont les avantages et les inconvénients pour chacun? Est-ce que quelque chose a changé depuis 2009?


ont également trouvé ces articles utiles: linuxquestions.org/565242#2986414 et lists.gnupg.org/022764
RubyTuesdayDONO

Réponses:


73

Recommandations dignes de confiance

Lors du dernier message, il y avait encore un débat sur la modification des algorithmes par défaut toujours trouvés dans les archives Web qui avaient obtenu un consensus approximatif, le passage aux clés RSA 2k par défaut a été effectué.

Debian recommande d' utiliser une clé 4k RSA dans son document sur l' utilisation des sous - clés et debian-clés de fichier readme. Une grande majorité des trois quarts environ des clés du trousseau de développeurs Debian est (toujours) DSA / Elgamal (comptée par grepping dans la sortie de gpg).

Dans une interview avec iX (magazine allemand d'informatique, numéro 11/2013, également disponible en ligne gratuitement ), l'inventeur de PGP Phil Zimmermann recommande "une longueur minimale de 3k lors de l'utilisation de RSA", bien que les clés 1k ne soient pas encore cassées. Mais ils sont "à la portée d'attaquants riches en ressources".

Concernant la sécurité

À l'heure actuelle, on dit que les deux sont sécurisés pour des tailles de clé adéquates (4k recommandé pour RSA, 2k nécessaires pour DSA2, sinon vous utiliserez DSA1 qui utilise SHA-1 ).

Pour sélectionner une longueur de clé RSA , consultez un aperçu de la force réelle fournie par NIST (p. 64). Il est facile de voir que la force ne croît pas linéairement avec la longueur de la clé (et le temps de calcul), donc double taille ne signifie pas «double sécurité».

Il y avait un problème avec l'implémentation DSA d'OpenSSL sur Debian , mais cela était dû à l'utilisation de mauvaises données aléatoires et aurait pu se produire avec RSA également.

Choisir entre RSA et DSA2

pro RSA

  • RSA est plus répandu, bien que non nécessaire dans le standard OpenPGP, toutes les mises en œuvre majeures peuvent le gérer; DSA2 pas (encore)
  • RSA offre une vérification des signatures beaucoup plus rapide

pro DSA2

  • Des signatures plus petites, mais elles sont petites quand même; pour la signature de courrier électronique et de code probablement négligeable
  • Création de clé plus rapide (peut être utile sur les appareils à faible consommation d'énergie et embarqués tels que les mobiles et les routeurs)
  • Un peu plus rapide pour la signature

Ma propre décision

Lors de la création récente d'une nouvelle clé OpenPGP, j'ai décidé de choisir 8k RSA pour les clés primaires et 4k RSA comme sous-clés à utiliser au quotidien. Les signatures RSA sont rapides à vérifier de toute façon et les énormes signatures 8k ne sont utilisées que pour signer d'autres clés, mais 8k devraient être considérées comme suffisantes pendant très longtemps. 4k convient aux sous-clés actuelles, car il est peu coûteux de la révoquer sans perdre toutes vos signatures.

La création de cette clé 8k a pris environ 20 minutes sur mon Core 2 Duo T9300, prenez donc votre temps et travaillez (pour alimenter la source aléatoire).


0

Alors que j’ai opté pour une clé principale RSA 4K avec une sous-clé de signature RSA 3K et une sous-clé de cryptage El-Gamal 4K. La seule raison pour laquelle je n'ai pas opté pour une clé principale supérieure à ce stade-ci est due à la prévalence d'utilisateurs disposant d'appareils mobiles qui ont vraiment du mal à gérer les clés plus grandes.

Bien sûr, j’ai des touches plus grandes pour certains objectifs spécifiques, mais ce n’est généralement pas pour la communication avec d’autres.


1
pourquoi El-Gamal pour le cryptage?
code_monk
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.