Existe-t-il une définition de longueur clé pour DH ou DHE?
J'ai trouvé ça sur wiki
L'algorithme Finie Field Diffie-Hellman a à peu près la même force de clé que RSA pour les mêmes tailles de clé. Le facteur de travail pour casser Diffie-Hellman est basé sur le problème du logarithme discret, qui est lié au problème de factorisation d'entier sur lequel la force de RSA est basée. Ainsi, une clé Diffie-Hellman de 3072 bits a à peu près la même force qu'une clé RSA de 3072 bits.
Comment définir une longueur de clé Diffie-Hellman?
Selon le pricipe DH:
Y = g ^ X mod p
p, g, X ou Y? Lequel vaut 3072 bits selon l'opinion du wiki
Les tailles de clé sont traditionnelles . J'entends par là qu'il n'y a pas de notion universelle, mathématiquement acceptée, de "taille de clé" qui correspondrait à tous les algorithmes. Pour les algorithmes symétriques, il est habituel d'avoir des clés qui sont des séquences de bits d'une longueur donnée n, de sorte que toutes les séquences possibles de longueur n (il y a 2n d'entre eux) sont des clés acceptables; dans ce cas, les cryptographes ont tendance à parler de n de "taille de clé". Il y a déjà place pour des problèmes ici, avec DES, qui a des clés 64 bits dont seulement 56 bits sont utilisés, donc DES peut être dit utiliser des clés 56 bits. Similaire, 3DES utilise une clé de 192 bits qui est en fait une clé de 168 bits; et, pour aggraver la confusion, il existe un algorithme connu qui (théoriquement) casse 3DES en effort 2112 donc on dit parfois que 3DES a le niveau de sécurité "112 bits". Un autre algorithme gênant est RC2, qui a un paramètre supplémentaire de "taille de clé efficace" qui abaisse la résistance de RC2 contre la force brute jusqu'à une valeur configurable, même si la clé est plus longue.
Pour la cryptographie asymétrique, les choses sont plus complexes puisque les clés publiques et privées ne sont plus "juste des séquences de bits". Par exemple, une clé publique RSA se compose de deux entiers, du module et du exposant public. Il est traditionnel d'utiliser la taille du module comme "taille de clé RSA", même s'il n'est pas possible de placer une clé publique RSA entière dans une séquence de bits de cette taille (car il n'y aurait pas de place pour l'exposant public) .
Pour Diffie-Hellman , la norme est ANSI X9.42 . Cette norme est systématiquement évite pour parler de " la taille de clé". Au lieu de cela, il parle toujours de "la taille de p" et "de la taille de q". Les deux tailles sont importantes pour la sécurité, mais pas dans la même plage. A savoir, DH fonctionne avec des nombres modulo un grand premier p, et avec un générateur g. Le générateur g "génère" un sous-groupe d'entiers modulo p: si l'on considère les valeurs successives 1, g, g2, g3 ... modulo p, vous reviendrez à 1 à un moment donné. L'ordre de g est le plus petit entier k>> 0 tel que gk = 1 mod p. Les mathématiques nous disent que k divise nécessairement p-1. Avec ces notations:
DH peut être cassé si logarithme discret modulo p, avec base g, est cassé. Il existe certains algorithmes dont le coût dépend de la taille de p, donc vous voulez que p soit suffisamment grand pour rendre ces algorithmes trop chers. L'algorithme le plus connu de ce type est une variante de General Number Field Sieve et l'enregistrement courant, pour un module "aléatoire" p est de 530 bits (c'est possible de créer un module de forme spéciale p qui rend le logarithme discret plus facile, mais un nombre premier aléatoire évitera cela avec une probabilité écrasante).
Le logarithme discret peut également être rompu en un temps qui dépend à la fois de la taille de l'exposant utilisé et de l'ordre de k. Si, au sein de Diffie-Hellman, une partie sélectionne son exposant privé dans une plage de t valeurs successives, et le plus grand facteur premier de k (l'ordre de g) est q, alors les algorithmes de ce type vont casser DH dans un temps qui dépend du plus petit des q et t. Ce sont les algorithmes "génériques", dont le temps d'exécution est proportionnel à racine carrée de q (ou t, s'il est plus petit).
Donc, fondamentalement, vous avez trois tailles :
- La taille de t pour la génération de clé privée DH: chaque partie impliquée génère une clé privée DH aléatoire dans la plage 1..t-1.
- La taille de q, qui est le plus grand facteur premier de l'ordre k du générateur g.
- La taille du module p.
Dans certains protocoles, q est généré explicitement, donc avec une taille connue, puis p est généré de telle sorte que p-1 est un multiple de q. Alors g est sélectionné pour avoir l'ordre exactement q ( gq = 1 mod p). Dans ces protocoles, nous définissons t = q: q est connu, et les systèmes génèrent des clés privées dans le 1..q-1 plage.
Dans certains autres protocoles, p est généré comme un soi-disant "prime sûre", c'est-à-dire tel que (p-1)/2 est également premier. Dans ce cas, p = 2q + 1. Pour ces protocoles, les clés privées DH seront générées dans une plage plus petite t, généralement de 160 à 256 bits.
Dans encore quelques autres protocoles, q n'est pas du tout connu, et est simplement supposé être assez grand. C'est le cas de SSL/TLS (pour les suites de chiffrement DHE, le Server Key Exchange le message contient p et g mais pas q, donc le client ne sait pas q). Là encore, une plage t est utilisée.
Nous voulons n - sécurité des bits pour certains n, ce qui signifie que briser le l'algorithme doit avoir un coût moyen 2n opérations. Pour atteindre un tel niveau de sécurité, la taille de q et la taille de t doivent être au moins 2n bits, mais p doit être beaucoup plus grand. Pour donner des chiffres, on estime généralement que si vous recherchez n = 112 (sécurité 112 bits, ce que vous obtenez pour le cryptage symétrique avec 3DES), vous avez besoin de q et t doit être d'au moins 224 bits, mais p doit être d'au moins 2048 bits.
Résumé: quand on parle de DH, une "grande" taille comme 1024 ou 3072 signifie normalement "la taille de p ", alors qu'une" petite "taille comme 160 ou 256 signifie normalement" la taille de q "ou" la taille de t ". Il n'y a pas de norme pour "la taille", et en effet la norme ne définit pas une taille unique pour tous.
Dans votre citation Wikipédia, les "3072 bits" sont de la taille de p (le module). La valeur y, qui est une clé publique DH, est dans la plage 1..p-1, donc également un nombre de 3072 bits (ou légèrement plus petit). L'exposant privé x est choisi dans une plage 1..t-1 qui mai a une taille de 3072 bits également (ou même plus) mais une plage beaucoup plus petite, jusqu'à (disons) 256 bits, est parfaitement acceptable pour la sécurité.
Comme le dit @Polynomial, voir ce site pour les comparaisons entre les tailles de clés.
Diffie-Hellman a deux tailles de clé: la taille de clé de journal discrète et la taille de groupe de journal discret. Ceux-ci sont mappés sur q et p respectivement.
En 2013, les tailles raisonnables sont de 224 bits pour q et de 2048 bits pour p.
Vous pouvez utiliser KeyLength pour obtenir des estimations pour différentes durées de vie des clés et marges de sécurité.
Cela vaut également la peine de regarder cette question sur Crypto SE, qui fournit plus de détails techniques à ce sujet.