Optez pour RSA.

DSA est plus rapide pour la génération de signature mais plus lent pour la validation, plus lent lors du cryptage mais plus rapide lors du décryptage et la sécurité peut être considérée comme équivalente par rapport à une clé RSA de longueur de clé égale. C'est la ligne de frappe, maintenant une justification.

La sécurité de l'algorithme RSA est basée sur le fait que la factorisation de grands entiers est connue pour être "difficile", alors que la sécurité DSA est basé sur le problème du logarithme discret. Aujourd'hui, l'algorithme connu le plus rapide pour factoriser de grands entiers est le General Number Field Sieve, également l'algorithme le plus rapide pour résoudre le problème du logarithme discret dans les champs finis modulo un grand p premier comme spécifié pour DSA.

Maintenant, si la sécurité peut être considérée comme égale, nous préférerions bien sûr l'algorithme le plus rapide. Mais encore une fois, il n'y a pas de gagnant clair.

Vous pouvez jeter un œil à cette étude ou, si OpenSSL est installé sur votre machine, exécutez openssl speed . Vous verrez que DSA est plus rapide pour générer une signature, mais beaucoup plus lent lors de la vérification d'une signature de même longueur de clé. La vérification est généralement ce que vous voulez être plus rapide si vous traitez, par exemple avec un document signé. La signature est générée une fois - donc ça va si cela prend un peu plus de temps - mais la signature du document peut être vérifiée beaucoup plus souvent par les utilisateurs finaux.

Les deux prennent en charge une certaine forme de méthode de cryptage, RSA hors du box et DSA en utilisant un El Gamal. DSA est généralement plus rapide pour le décryptage mais plus lent pour le cryptage, avec RSA c'est l'inverse. Encore une fois, vous voulez que le décryptage soit plus rapide ici, car un document chiffré peut être déchiffré plusieurs fois.

En termes commerciaux, RSA est clairement le gagnant, les certificats RSA commerciaux sont beaucoup plus largement déployés que les certificats DSA.

Mais j'ai gardé l'argument tueur pour la fin: man ssh-keygen dit qu'une clé DSA doit avoir exactement 1024 bits de long pour être conforme à la FIPS 186-2. Ainsi, bien qu'en théorie des clés DSA plus longues soient possibles (FIPS 186-3 les autorise également explicitement), vous êtes toujours limité à 1024 bits. Et si vous prenez les considérations de cet [article], nous ne sommes plus sécurisés avec 1024 bits pour RSA ou DSA.

Donc, aujourd'hui, vous êtes mieux avec un RSA 2048 ou 4096 bits clé.

Pour le moment, la question est un peu plus large: RSA vs DSA vs ECDSA vs Ed25519 . Donc:

Une présentation à BlackHat 2013 suggère que des progrès significatifs ont été accomplis dans la résolution des problèmes de complexité dont la force de DSA et d'autres algorithmes est fondé, donc ils peuvent être mathématiquement cassés très bientôt. De plus, l'attaque peut également être possible (mais plus difficile) à étendre à RSA.

La présentation suggère d'utiliser la cryptographie à courbe elliptique à la place. Les algorithmes ECC pris en charge par OpenSSH sont ECDSA et, depuis OpenSSH 6.5, Ed25519.

OpenSSH ne prend en charge que les courbes NIST pour ECDSA et selon cette étude ces courbes semblent vraiment suspectes pour les portes dérobées de la NSA . Et si la NSA peut déjà la casser, alors ce ne sera pas aussi difficile à craquer pour quelqu'un d'autre qu'une courbe appropriée le serait. Ed25519 est la même chose mais avec une meilleure courbe, c'est donc le pari le plus sûr contre l'algorithme sous-jacent étant mathématiquement cassé.

De plus, DSA et ECDSA ont une propriété désagréable: ils nécessitent un paramètre généralement appelé k pour être complètement aléatoire, secret et unique. En pratique, cela signifie que si vous vous connectez à votre serveur à partir d'une machine avec un mauvais générateur de nombres aléatoires et par ex. le même k est utilisé deux fois, un observateur du trafic peut déterminer votre clé privée. (source: Wikipedia sur DSA et ECDSA, également ceci).

En résumé:

• Ne jamais utiliser DSA ou ECDSA .
• Ed25519 est probablement le plus puissant mathématiquement (et aussi le plus rapide), mais pas encore largement pris en charge. En prime, il a un cryptage plus fort (protection par mot de passe) de la clé privée par défaut que les autres types de clés.
• RSA est le meilleur pari si vous ne pouvez pas utiliser Ed25519 .

En SSH, côté client, le choix entre RSA et DSA n'a pas beaucoup d'importance, car les deux offrent une sécurité similaire pour la même taille de clé (utilisez 2048 bits et vous serez heureux).

Historiquement, la version 1 du protocole SSH ne prenait en charge que les clés RSA. Lorsque la version 2 a été définie, RSA était encore brevetée, de sorte que la prise en charge de DSA a été ajoutée, de sorte qu'une mise en œuvre open source sans brevet puisse être réalisée. Le brevet RSA a expiré il y a plus de 10 ans, il n'y a donc pas de souci maintenant.

Théoriquement, dans certaines situations très spécifiques, vous pouvez avoir un problème de performance avec l'un ou l'autre: si le serveur est très petit machine (disons, un i486), il préférera les clients avec des clés RSA, car la vérification d'une signature RSA est moins coûteuse en calcul que la vérification d'une signature DSA. À l'inverse, une signature DSA est plus courte (généralement 64 octets contre 256), donc si vous manquez de bande passante, vous préférerez DSA. Quoi qu'il en soit, vous aurez du mal à détecter ces effets, et encore moins à les trouver importants.

Sur le serveur , une clé DSA est préférable, car alors l'échange de clés utilisera un Clé Diffie-Hellman transitoire, qui ouvre la voie à "Perfect Forward Secrecy" (c'est-à-dire que si un méchant vole la clé privée du serveur, il ne peut toujours pas décrypter les connexions passées qu'il aurait enregistrées).

Un autre avantage important de RSA par rapport à DSA et ECDSA est que vous n'avez jamais besoin d'un générateur de nombres aléatoires sécurisé pour créer des signatures.

Pour générer une signature, (EC) DSA a besoin d'une valeur qui doit être aléatoire, secret / imprévisible et ne peut plus jamais être utilisé. Si l'une de ces propriétés est violée, il est possible de récupérer de manière triviale la clé privée à partir d'une ou deux signatures .

Cela s'est déjà produit (une fois avec un correctif cassé d'OpenSSL PRNG dans Debian, et une fois avec un bogue dans l'implémentation SecureRandom d'Android), et c'est assez difficile à éviter complètement.

Avec RSA, dans ces situations, seule votre clé de session éphémère aurait été compromise, si la clé d'authentification réelle des paires ont déjà été créées à l'aide d'un PRNG correctement prédéfini.

Théoriquement, il existe un moyen de faire en sorte que les signatures DSA (EC) dépendent du message et de la clé privée, ce qui peut éviter le total échec en cas de panne du RNG, mais jusqu'à ce que cela soit intégré à votre client SSH (il n'y a pas de version d'OpenSSL incluant le correctif pour le moment), j'irais certainement avec les clés RSA.

Ne sachant pas grand-chose sur la cryptographie, en tant qu'utilisateur d'OpenSSH, je m'en tiens à un simple fait: dans http://www.openssh.com/legacy.html, qui indique que SHA1 est désormais désactivé par défaut car il est considéré comme faible:

OpenSSH 7.0 et supérieur désactive de la même manière l'algorithme de clé publique ssh-dss (DSA) . Il est également faible et nous déconseillons son utilisation.

Le calcul n'a peut-être pas d'importance. Ce fil semble pré-Snowden. Voici un article de Reuters daté du 20 décembre 2013:

(Reuters) - En tant qu'élément clé d'une campagne visant à intégrer un logiciel de chiffrement dans lequel il pourrait être largement utilisé produits informatiques, la National Security Agency des États-Unis a conclu un contrat secret de 10 millions de dollars avec RSA, l'une des entreprises les plus influentes du secteur de la sécurité informatique, a appris Reuters.

Des documents divulgués par l'ancien sous-traitant de la NSA Edward Snowden montrent que la NSA a créé et promulgué une formule erronée pour générer des nombres aléatoires afin de créer une «porte dérobée» dans les produits de cryptage, a rapporté le New York Times en septembre. Reuters a rapporté plus tard que RSA est devenu le distributeur le plus important de cette formule en la transformant dans un outil logiciel appelé Bsafe qui est utilisé pour améliorer la sécurité des ordinateurs personnels et de nombreux autres produits.

Jusqu'à présent, RSA a reçu 10 millions de dollars dans un accord définissant la formule NSA comme méthode préférée ou par défaut pour la génération de nombres dans le logiciel BSafe, selon deux sources proches du contrat. Bien que cette somme puisse sembler dérisoire, elle représentait plus d'un tiers des revenus que la division concernée de RSA avait encaissée pendant toute l'année précédente, selon les dépôts de titres.

Au cours de ce vendredi scientifique podcast Ira demande à Matt Green, à Martin Hellman (inventeur de la cryptographie à clé publique) et à Phil Zimmerman (créateur de PGP) ce qu'ils pensent que la NSA a craqué:

(vers 17: 26)

Ira : Quelles sont certaines des choses dans lesquelles nous savons que la NSA a fait irruption?

Matt : Nous avons donc entendu un certain nombre de choses que nous pouvons probablement créditer pour de vrai. … Des générateurs de nombres aléatoires… nous savons que la NSA à travers le NIST… a très probablement mis des portes dérobées dans certains de ces algorithmes standard qui leur permettent essentiellement de casser complètement ces systèmes.

Ira : Vous voulez dire que la NSA a créé ces portes dérobées?

Matt : C'est exactement ça. Le NIST travaille donc avec la NSA - et ils sont tenus de le faire par la loi. Nous pensions que la NSA aidait le NIST en développant des normes plus sûres pour les Américains. Nous soupçonnons maintenant - et avons des preuves solides à croire - que la situation était exactement le contraire; que le NIST était utilisé pour publier des normes que la NSA pourrait briser.

Compte tenu de ces récentes révélations, la force des algorithmes semble largement hors de propos. RSA semble avoir été une société privée rachetée par la NSA, et DSA a été créée par le NIST lui-même, ce qui, selon ces experts, est en grande partie une façade pour la recherche cryptographique de la NSA.

En d'autres termes, c'est vraiment peu importe si vous utilisez les générateurs de nombres aléatoires fournis avec à peu près n'importe quel ordinateur moderne, ce que font OpenSSH et d'autres.

Choisissez celui qui est le plus rapide pour ce que vous voulez. Dans mon cas, je réutilise la même clé pour beaucoup de choses, donc la vitesse de génération plus rapide de DSA est moins souhaitable. De plus, il y a peut-être une chance folle que RSA soit en fait une entité indépendante du NIST et de la NSA, alors que nous savons que DSA a été créé par le NIST.

Personnellement, j'utilise simplement des clés de 1028 bits car, comme nous l'avons vu , cela n'a vraiment pas d'importance à moins que quelqu'un vous impose une exigence qui croit toujours que de plus grandes clés vous protégeront. Le tout n'est en grande partie qu'un ennui pour quiconque cherche à s'introduire par effraction.

RSA et DSA sont deux algorithmes complètement différents. Les clés RSA peuvent aller jusqu'à 4096 bits, où DSA doit être exactement de 1024 bits (bien qu'OpenSSL en permette plus.) Selon Bruce Schneier, «les clés DSA et RSA avec la même longueur de clés sont à peu près identiques en difficulté à craquer».

Le problème avec ECDSA n'est pas tant les portes dérobées. Bernstein / Lange mentionnent spécifiquement que l'analyse cryptographique des courbes n'attaque pas des courbes spécifiques, mais des classes de courbes (voir diapositive 6).

Le problème avec ECDSA est que les courbes NIST sont difficiles à implémenter correctement (c.-à-d. temps constant et avec toutes les vérifications appropriées) par rapport à Curve25519. OpenSSL a une implémentation P256 à temps constant, donc OpenSSH est sûr à cet égard.

Si vous êtes toujours préoccupé par les courbes NIST, OpenSSH a récemment ajouté la prise en charge du schéma Ed25519