En SSH, deux algorithmes sont utilisés: un algorithme d'échange de clés (Diffie-Hellman ou la variante de courbe elliptique appelée ECDH) et un algorithme de signature. L'échange de clé donne la clé secrète qui sera utilisée pour crypter les données pour cette session. La signature permet au client de s’assurer qu’il communique avec le bon serveur (une autre signature, calculée par le client, peut être utilisée si le serveur applique l’authentification client par clé).

ECDH utilise un courbe ; la plupart des logiciels utilisent la courbe standard NIST P-256. Curve25519 est une autre courbe, dont le "argument de vente" est qu'elle est plus rapide, pas plus forte, que le P-256. La différence de performances est très faible en termes humains: nous parlons de moins d'une milliseconde de calculs sur un petit PC, et cela ne se produit qu'une seule fois par session SSH. Vous ne le remarquerez pas. Aucune des deux courbes ne peut être considérée comme «plus forte» que l’autre, ni en pratique (elles sont toutes les deux assez éloignées dans le domaine du «ne peut pas le casser») ni académiquement (les deux sont au «niveau de sécurité 128 bits»).

Même lorsque ECDH est utilisé pour l'échange de clés, la plupart des serveurs et clients SSH utiliseront des clés DSA ou RSA pour les signatures. Si vous voulez un algorithme de signature basé sur des courbes elliptiques, alors c'est ECDSA ou Ed25519; pour certaines raisons techniques en raison de la définition précise de l'équation de la courbe, c'est ECDSA pour P-256, Ed25519 pour Curve25519. Là encore, ni l'un ni l'autre n'est plus fort que l'autre, et la différence de vitesse est bien trop petite pour être détectée par un utilisateur humain.Cependant, la plupart des navigateurs (y compris Firefox et Chrome) ne prennent plus en charge ECDH (dh aussi).

L'utilisation du P-256 devrait offrir une meilleure interopérabilité dès maintenant, car Ed25519 est beaucoup plus récent et moins répandu. Mais, pour un serveur donné que vous configurez, et auquel vous souhaitez accéder depuis vos propres machines, l’interopérabilité n’a pas beaucoup d’importance: vous contrôlez à la fois les logiciels client et serveur.

Donc, fondamentalement, le choix est une question d'esthétique, c'est-à-dire complètement à vous, sans raison rationnelle. De toute façon, les problèmes de sécurité ne seront pas causés par ce choix; les algorithmes cryptographiques sont la partie la plus puissante de tout votre système, pas la plus faible.

Dans l ' Introduction à Ed25519, il y a des avantages en termes de vitesse et des avantages en matière de sécurité. L'un des avantages de sécurité les plus intéressants est qu'il est immunisé contre plusieurs attaques de canaux secondaires:

• Aucun indice de tableau secret. Le logiciel ne lit ni n'écrit jamais de données à partir d'adresses secrètes dans la RAM; le modèle d'adresses est complètement prévisible. Le logiciel est donc à l'abri des attaques de synchronisation du cache, des attaques d'hyperthreading et d'autres attaques de canal secondaire qui reposent sur une fuite d'adresses via le cache du processeur.
• Aucune condition de branche secrète. Le logiciel n'effectue jamais de branchements conditionnels basés sur des données secrètes; le schéma des sauts est tout à fait prévisible. Le logiciel est donc immunisé contre les attaques par canal secondaire qui reposent sur une fuite d'informations via l'unité de prédiction de branche.

À titre de comparaison, plusieurs attaques de synchronisation de cache dans le monde réel ont été démontrées sur divers algorithmes. http://en.wikipedia.org/wiki/Timing_attack

Il y a un avantage pratique important d'Ed25519 par rapport au DSA (EC): cette dernière famille d'algorithmes se brise complètement lorsqu'elle est utilisée pour des signatures avec un générateur de nombres aléatoires cassés. Un tel échec RNG est arrivé avant et pourrait très bien se reproduire.

Théoriquement, les implémentations peuvent protéger contre ce problème spécifique, mais c'est beaucoup plus difficile pour vérifier que les deux extrémités utilisent une implémentation correcte plutôt que de simplement préférer ou appliquer (selon vos besoins de compatibilité) un algorithme qui spécifie explicitement un comportement sécurisé (Ed25519).

J'avais l'impression que Curve25519 EST en fait plus sûr que les courbes NIST en raison de la forme de la courbe qui la rend moins sensible à diverses attaques de canaux latéraux ainsi qu'aux échecs d'implémentation. Voir: http://safecurves.cr.yp.to

Ed25519 a l'avantage de pouvoir utiliser la même clé pour signer l'accord de clé (normalement, vous ne faites ceci). Je ne connais pas suffisamment les mathématiques pour dire si c'est une propriété du fait qu'il s'agit d'une courbe d'Edwards, bien que je sache qu'elle est convertie dans le système de coordonnées de Montgomery (effectivement en Curve25519) pour un accord clé ... Ed25519 est plus qu'une courbe, il spécifie également la génération de clé déterministe entre autres (par exemple le hachage), qu'il convient de garder à l'esprit. C'est une chose frustrante à propos des implémentations DJB, en l'occurrence, car elles doivent être traitées différemment pour maintenir l'interopérabilité.

Une chose à laquelle aucune réponse n'a jusqu'ici été abordée directement est que vos questions mélangent plusieurs noms plus ou moins sans rapport entre eux comme s'il s'agissait d'alternatives équivalentes, ce qui n'est pas vraiment le cas.

ECDH et ECDSA ne sont que des noms de méthodes cryptographiques.

ECDH est une méthode d'échange de clés que deux parties peuvent utiliser pour négocier une clé sécurisée sur une canal de communication. C'est une variante de la méthode d'échange de clés DH (Diffie-Hellman). ECDH signifie Diffie-Hellman à courbe elliptique . Pourtant, ECDH n'est qu'une méthode, ce qui signifie que vous ne pouvez pas simplement l'utiliser avec une courbe elliptique spécifique, vous pouvez l'utiliser avec de nombreuses courbes elliptiques différentes.

ECDSA est un algorithme de signature qui peut être utilisé pour signer un élément de données de telle sorte que toute modification des données entraînerait l'échec de la validation de la signature, mais un attaquant ne serait pas en mesure de signer à nouveau correctement les données après une telle modification. Il s'agit d'une variante de DSA (Digital Signature Algorithm). ECDSA signifie Algorithme de signature numérique à courbe elliptique . ECDSA décrit également uniquement une méthode qui peut être utilisée avec différentes courbes elliptiques.

La sécurité de ECDH et ECDSA dépend donc de deux facteurs:

1. La sécurité de la méthode elle-même ? Si la méthode n'est pas sécurisée, la meilleure courbe du mot ne changerait rien.
2. Quelle est la sécurité de la courbe utilisée? Si la courbe n'est pas sécurisée, elle ne jouera aucun rôle si la méthode l'est théoriquement.

Curve25519 est le nom d'une courbe elliptique spécifique. D'autres courbes sont nommées Curve448, P-256, P-384 et P-521.

Ed25519 est le nom d'une variante concrète de EdDSA . Lors de l'exécution d'EdDSA en utilisant SHA-512 et Curve25519 , cette variante est nommée Ed25519. EdDSA est un algorithme de signature, tout comme ECDSA.

Donc, si une implémentation dit simplement qu'elle utilise ECDH pour l'échange de clés ou ECDSA pour signer des données, sans mentionner aucune courbe spécifique, vous pouvez généralement supposer qu'elle utilisera les courbes NIST (P-256, P-384 ou P- 512), mais l'implémentation devrait toujours nommer la courbe utilisée de manière explicite.

Pour répondre à votre question sur la sécurité: ECDH et ECDSA se sont avérés être des méthodes de conception et d'échange de clés sécurisées, donc la sécurité de ECDH et ECDSA dépend beaucoup du fait que quelqu'un trouve un moyen de briser la cryptographie elliptique en général (peu probable mais pas impossible) ou de trouver une faille dans les courbes utilisées (plus probable).

La raison pour laquelle certaines personnes préfèrent Curve25519 aux courbes standard du NIST est le fait que le NIST n'a pas clairement documenté pourquoi il a choisi ces courbes en faveur d'alternatives existantes. La déclaration générique " Les courbes ont été ostensiblement choisies pour une sécurité et une efficacité de mise en œuvre optimales " sonne beaucoup comme un balderdash marketing et ne convaincra pas les experts en cryptographie.

Le NIST a également normalisé une cryptographie à courbe elliptique basée sur un générateur de nombres aléatoires (Dual_EC_DRB) en 2006 et l'époque de New York a affirmé (après avoir examiné les mémos divulgués par Edward Snowden) que c'était la NSA qui avait influencé le NIST pour normaliser ce générateur de nombres aléatoires spécifique. Une énorme faiblesse a été découverte dans ce générateur et on pense qu'il s'agit d'une porte dérobée intentionnelle placée par la NSA pour pouvoir casser le cryptage TLS basé sur ce générateur. L'ANSI a apparemment découvert la faiblesse lorsque Dual_EC_DRB leur a été soumis pour la première fois, mais bien qu'il sache comment l'éviter, ils n'ont ni amélioré l'algorithme, ni rendu public les faiblesses, on pense donc qu'ils n'étaient pas autorisés à le faire (ordre de bâillon ). Lorsque la faiblesse est devenue publique, la norme a été retirée en 2014.

Avec ces connaissances de base, bien sûr, les gens ont commencé à se demander si la source des mystérieux paramètres de la courbe du NIST était en fait également la NSA, car ces courbes ont peut-être aussi des faiblesses cachées qui ne sont pas encore connues du public, mais la NSA peut le savoir. à leur sujet et ainsi pouvoir casser la cryptographie basée sur ces courbes. Il n'y a aucune preuve pour cette affirmation, pas même une preuve présomptive, mais cela semble sûrement possible et plus réaliste qu'un conte de fées. C'est pourquoi les gens ont perdu confiance dans ces courbes et sont passés à des alternatives où il est hautement improbable que celles-ci aient été influencées par des services secrets du monde entier.

Curve25519 a été publiée par le mathématicien et cryptologue germano-américain Daniel J Bernstein en 2005, qui a également conçu le célèbre chiffrement de flux Salsa20 et sa variante ChaCha20 maintenant largement utilisée. Il a également inventé l'authentification de message Poly1305. Google a décidé que ChaCha20 en combinaison avec Poly1305 est une alternative sécurisée à utiliser dans TLS après que RC4 a dû être supprimé car l'algorithme a été cassé. Il nécessite beaucoup moins de puissance de calcul que l'utilisation du bloc de chiffrement AES (très utile pour les appareils mobiles car il permet d'économiser la batterie), mais on pense qu'il offre une sécurité comparable. ChaCha20 / Poly1305 est normalisé dans la RFC 7905 et largement utilisé aujourd'hui dans la communication client-serveur TLS à partir d'aujourd'hui. Donc, si Bernstein était un espion de la NSA, ce qui est très improbable, nous serions déjà tous condamnés, car alors TLS tel qu'il est souvent utilisé aujourd'hui serait probablement inutile pour protéger les données des yeux des services secrets.