Y a-t-il une raison particulière d'utiliser Diffie-Hellman sur RSA pour l'échange de clés?
Je considère souvent que RSA est recommandé comme méthode d'échange de clés. Cependant, la méthode d'échange de clés Diffie-Hellman semble également sécurisée.
Y a-t-il des considérations à prendre en compte qui conduiraient à utiliser un algorithme plutôt qu'un autre?
La situation peut être confuse, alors réglons les choses.
RSA est deux algorithmes, un pour le chiffrement asymétrique et un pour signatures numériques . Ce sont deux bêtes distinctes; bien qu'ils partagent la même opération mathématique de base et le même format pour les clés, ils font différentes choses de différentes manières. Diffie-Hellman est un algorithme échange de clés , qui est encore un autre type d'algorithme. Étant donné que les algorithmes ne font pas la même chose, vous pouvez préférer l'un à l'autre en fonction du contexte d'utilisation.
Le chiffrement asymétrique et l'échange de clés sont quelque peu équivalents: avec le chiffrement asymétrique, vous pouvez effectuer un échange de clés en générant une clé symétrique aléatoire (un tas d'octets aléatoires) et en le chiffrant avec la clé publique du destinataire. Inversement, vous pouvez effectuer un chiffrement asymétrique avec échange de clés en utilisant la clé résultant de l'échange de clés pour chiffrer les données avec un algorithme symétrique, par ex. AES . De plus, Diffie-Hellman est un algorithme d'échange de clés aller-retour: le destinataire envoie sa moitié ("clé publique DH"), l'expéditeur calcule sa moitié, obtient la clé, chiffre, envoie tout le lot au destinataire, le destinataire calcule la clé , décrypte. Ceci est compatible avec un système de communication unique, en supposant une pré-distribution de la clé publique, c'est-à-dire qu'il fonctionne avec les e-mails.
Donc pour le reste de cette réponse, je suppose que nous parlons de RSA cryptage.
Perfect Forward Secrecy est une caractéristique astucieuse qui peut être résumée comme suit: le cryptage réel est effectué avec une clé que nous ne conservons pas autour, donc immunisé contre le vol ultérieur. Cela ne fonctionne que dans une configuration dans laquelle nous ne voulons pas garder les données cryptées, c'est-à-dire pas pour les e-mails (l'e-mail doit rester crypté dans la boîte aux lettres), mais pour le transfert de données comme SSL/TLS .
Dans ce cas, pour obtenir PFS, vous devez générer une paire de clés transitoire (chiffrement asymétrique ou échange de clés) pour le chiffrement réel; puisque vous avez généralement aussi voulez une sorte d'authentification, vous devrez peut-être une autre paire de clés non transitoire au moins d'un côté. C'est ce qui se passe en SSL avec les suites de chiffrement "DHE": le client et le serveur utilisent DH pour l'échange de clés, avec les clés DH nouvellement générées (non stockées), mais le serveur a également besoin d'une paire de clés permanente pour les signatures (de type RSA, DSA, ECDSA ...).
Rien n'interdit intrinsèquement la génération d'une paire de clés RSA transitoire. En effet, ceci était pris en charge dans les anciennes versions de SSL; voir TLS 1. , section 7.4.3. Dans ce cas, l'utilisation d'une clé RSA éphémère n'était pas obligatoire pour PFS, mais bien au contraire: afin que les clés de chiffrement, bien qu'elles ne soient pas stockées, pourraient être cassées par la suite, même si la clé permanente du serveur était trop grande pour être ainsi brutalisée.
Il y a cependant un avantage de DH sur RSA pour générer des clés éphémères: produire une nouvelle paire de clés DH est extrêmement rapide (à condition que certains "paramètres DH", c'est-à-dire le groupe dans lequel DH est calculé, soient réutilisés, ce qui n'entraîne pas de risques supplémentaires, à notre connaissance). Ce n'est pas un problème très important pour les gros serveurs, car un serveur SSL très occupé pourrait générer une nouvelle paire de clés RSA "éphémère" toutes les dix secondes pour une très petite fraction de sa puissance de calcul, et la conserver dans RAM seulement, et pour seulement dix secondes, ce qui serait suffisant pour PFSish.
Néanmoins, le RSA éphémère est passé de mode et, plus important encore, de normalisation. Dans le contexte de SSL, si vous voulez PFS, vous devez utiliser DH éphémère (aka "DHE"), parce que c'est ce qui est défini et supporté par les implémentations existantes.
Si vous voulez pas vouloir PFS, en particulier si vous voulez pouvoir écouter vos propres connexions ou les connexions de vos services (dans le contexte d'un administrateur système protégeant ses utilisateurs à travers certains filtres, ou pour certaines activités de débogage), vous avez besoin de clés non éphémères. Là encore, RSA et DH peuvent être utilisés. Cependant, toujours dans le contexte de SSL, DH non éphémère nécessite que la clé du serveur, dans son certificat X.509, contienne une clé publique DH.
Les clés publiques DH dans les certificats ont été repoussées par le gouvernement fédéral américain à l'époque où RSA a été breveté. Mais ces jours sont révolus depuis longtemps. De plus, le support DH n'a jamais été aussi large que le support RSA. C'est en effet un exemple intéressant: DH a été approuvé par le gouvernement et normalisé par un organisme institutionnel (comme ANSI X9.42 ); d'autre part, le RSA a été normalisé par une entreprise privée qui n'était officiellement pas habilitée à produire des normes. Mais la norme RSA ( PKCS # 1 ) était libre de lecture pour tous, et même s'il y avait un brevet, c'était valable uniquement aux États-Unis, pas dans le reste du monde; et aux États-Unis, RSA (la société) a distribué une implémentation gratuite de l'algorithme (gratuite tant qu'elle était destinée à des usages non commerciaux). Les développeurs amateurs, dont Phil Zimmerman pour PGP, ont donc utilisé RSA, pas DH. Le prix de la norme n'est rien pour une entreprise, mais cela peut signifier beaucoup pour un individu. Cela démontre l'impulsion qui peut provenir, dans l'industrie du logiciel, d'amateurs.
C'est donc un avantage de RSA sur DH : la norme est disponible gratuitement.
Pour la sécurité , RSA s'appuie (plus ou moins) sur la difficulté de factorisation entière , tandis que DH s'appuie (plus ou moins) sur la difficulté de logarithme discret . Ce sont des problèmes distincts. Il se trouve que les algorithmes de rupture les plus connus pour la rupture sont des variantes du General Number Field Sieve , donc ils ont tous les deux la même complexité asymptotique. D'un point de vue de haut niveau, une clé DH 1024 bits est aussi robuste contre la cryptanalyse qu'une clé RSA 1024 bits.
Si vous regardez les détails, cependant, vous pouvez noter que la dernière partie de GNFS, la partie "algèbre linéaire", qui est le goulot d'étranglement dans le cas de grandes clés, est plus simple dans le cas de RSA. Cette partie consiste à réduire une matrice terriblement grande. Dans le cas de RSA, les éléments matriciels ne sont que des bits (on travaille en GF (2)), alors que pour DH les éléments matriciels sont des entiers modulo le grand premier p. Cela signifie que la matrice est mille fois plus grande pour DH que pour RSA. Étant donné que la taille de la matrice est le goulot d'étranglement, nous pourrions affirmer que DH-1024 est plus fort que RSA-1024.
C'est donc un autre avantage de DH: on peut affirmer qu'il donne une robustesse supplémentaire par rapport aux clés RSA de la même taille.
Toujours pour des raisons de sécurité, DH généralise sur d'autres groupes, tels que courbes elliptiques . Le logarithme discret sur les courbes elliptiques n'est pas le même problème que le logarithme discret modulo un grand premier; GNFS ne s'applique pas. Il n'y a donc pas un Diffie-Hellman, mais plusieurs algorithmes. La "cryptodiversité" est une bonne chose car elle nous permet de changer d'algorithme au cas où certains chercheurs trouveraient un moyen de casser facilement certains algorithmes.
En ce qui concerne les performances :
- RSA cryptage (avec la clé publique) est nettement moins cher (donc plus rapide) que n'importe quelle opération DH (même avec des courbes elliptiques).
- RSA décryptage (avec la clé privée) implique plus ou moins la même quantité de travail que l'échange de clés DH avec une résistance similaire. DH est un peu moins cher s'il utilise une paire de clés permanente, mais un peu plus cher si vous incluez le coût de construction d'une paire de clés éphémère.
- Dans le cas de SSL et DHE_RSA, le serveur doit générer une paire de clés DH et signez-la, et la signature inclut les valeurs aléatoires client et serveur, donc cela doit être fait pour chaque connexion. Donc, choisir "DHE_RSA" au lieu de "RSA" permet de doubler la facture du processeur sur le serveur pour SSL - mais cela n'a pas beaucoup d'importance en pratique. Il faut un serveur très occupé pour remarquer la différence.
- Une clé publique DH est plus grande à coder qu'une clé publique RSA, si la clé DH inclut les paramètres DH; il est plus petit sinon. Dans le cas de SSL, utiliser DHE_RSA au lieu de RSA signifie échanger un ou deux kilo-octets supplémentaires de données - là encore, une seule fois par client (en raison de la réutilisation de session SSL), ce n'est donc pas un point crucial. Dans certains protocoles spécialisés, l'ECDH (avec des courbes elliptiques) obtient un Edge important car les éléments publics sont beaucoup plus petits.
Si vous concevez un protocole dans une situation contrainte (par exemple impliquant des cartes à puce et des E/S sur infrarouge ou autre chose de faible puissance), ECDH sera probablement plus attractif que RSA.
Résumé: vous préférerez généralement RSA à DH, ou DH à RSA, en fonction des contraintes d'interopérabilité: l'une sera plus prise en charge que l'autre, selon le le contexte. La performance importe rarement (du moins pas autant qu'on le suppose souvent). Pour SSL, vous aurez besoin de DH car il s'agit en fait de DHE, et le "E" (comme éphémère) est agréable à avoir, à cause de PFS.
L'échange de clés éphémères DH fournit secret de transmission parfait , ce que RSA seul ne fait pas. Cela signifie que même si la clé à long terme est divulguée à une date ultérieure, les clés de session pour les connexions individuelles ne sont pas compromises, même si le flux de données complet est capturé.
Dans le contexte de SSL, Polynomial a raison: (EC) Les suites DHE utilisent un échange de clés éphémère en utilisant Diffie-Hellman. Étant donné que le serveur oublie la clé privée utilisée pour l'échange peu de temps après l'avoir utilisée, un compromis de la clé à long terme du serveur ne permet pas à un attaquant de décrypter toutes les communications passées, c'est-à-dire qu'il fournit Perfect Forward Secret .
Je recommande d'utiliser les suites ECDHE_RSA en SSL. Ils offrent une parfaite parfaite confidentialité, un niveau de sécurité élevé pour la confidentialité (128 bits si P256 est utilisé) et vous permettent d'utiliser le même certificat pour les connexions RSA héritées et les connexions ECDHE_RSA fortes.
La raison pour laquelle les concepteurs de protocoles utilisent DH pour l'échange de clés éphémères est la performance.
La génération d'une clé DH est relativement bon marché: il s'agit simplement d'une multiplication scalaire avec une base fixe (ou exponentiation si vous utilisez la notation multiplicative).
Le coût total d'un échange de clé éphémère utilisant ECDH est une multiplication scalaire avec une base fixe (key-gen) et une multiplication scalaire avec une variable (l'échange de clé réel) plus une opération de clé privée RSA utilisant la clé à long terme signant le clé publique éphémère.
La génération d'une clé RSA est beaucoup plus coûteuse, car vous devez trouver deux grands nombres premiers. Il est très coûteux de générer une nouvelle paire de clés RSA pour chaque connexion.
L'opération de clé privée RSA est également un peu plus chère qu'un échange de clés DH avec le même niveau de sécurité, mais cela ne nous a pas empêchés d'utiliser RSA avec des clés à long terme.
Avec ECC, l'écart de performances devient encore plus grand, en particulier à des niveaux de sécurité plus élevés. L'ECC 256 bits est assez courant (sécurité 128 bits), pour une sécurité équivalente avec RSA, vous auriez besoin d'une clé de 3000 bits.
Inversement, l'échange de clés RSA implique la clé RSA secrète du serveur, ce que (EC) DH ne fait pas.
Cela signifie que même si l'attaquant obtient des moyens de craquer votre clé RSA, il devra déployer des efforts de craquage pour chaque serveur/clé. Avec (EC) DH, en utilisant une attaque de type logjam, la majeure partie de l'effort de craquage va à la rupture de l'ensemble du groupe dit algébrique/elliptique. Après cela, rompre les connexions individuelles est bon marché.
Ainsi, alors que l'échange de clés RSA motive l'attaquant à ne casser que les clés des serveurs intéressants, (EC) l'échange de clés DH le motive à attaquer autant de connexions que possible pour obtenir le meilleur rapport coût/attaque.
Si vous vous demandez pourquoi cette propriété de (Im) perfectForwardSecrecy est peu connue, c'est probablement parce qu'aucune attaque de type logjam contre l'échange de clés Diffie-Hellman à courbe elliptique n'est actuellement connue.
Ceci est censé être un suivi/commentaire à publier https://security.stackexchange.com/a/35472/18595