OpenVPN dhparam
L'une des étapes de configuration OpenVPN exécute la commande openssl dhparam -out dh1024.pem 1024. La page de manuel me le dit 1024 valeur fait référence au nombre de bits.
- Pourquoi la valeur
1024suggéré par les exemples? - Dois-je utiliser une valeur plus grande comme
4096?- Quelle valeur dois-je utiliser, combien de bits suffisent, pourquoi?
- Les clés RSA 1024 bits sont désormais considérées comme faibles, et il est souvent suggéré d'utiliser 2048 bits ou plus. Ce type de situation s'applique-t-il également à ce fichier dhparam?
- La commande pour générer ce fichier semble prendre ~ 10 heures sur l'appliance I que j'utiliserai comme serveur OpenVPN. Est-il sûr de générer ce fichier sur une machine plus rapide et de le transférer, ou dois-je le traiter comme la plupart des clés privées et le conserver uniquement sur cet hôte? Quel doit être le secret de ce fichier?
Une grande partie de cela a été traitée auparavant. Voir ma réponse et réponse de Thomas à une question connexe pour plus d'informations sur les paramètres DH et DH.
Les paramètres ne sont que des nombres premiers, pas des clés. Ils n'ont pas besoin d'être uniques ou secrets, mais ils ne doivent pas non plus être spécialement conçus par un attaquant. La longueur du bit fait référence à la taille de la prime pas une clé, donc ce n'est pas directement comparable à RSA. Notez qu'une clé RSA de 2048 bits est composée d'une paire de nombres premiers de 1024 bits, vous êtes donc au même niveau en ce qui concerne la factorisation avec un nombre premier de 1024 bits par rapport à une clé RSA 2048.
Comme le souligne la réponse de Thomas liée ci-dessus, le nombre n'a pas besoin d'être unique ou secret, et en fait, votre bibliothèque de chiffrement peut fournir un DH prime qui fonctionnera très bien (en supposant que vous faites confiance à la source de la bibliothèque). Ou vous pouvez en générer un vous-même.
Détails supplémentaires à la lumière des découvertes récentes
Tout d'abord, les conseils sur la taille principale sont toujours corrects - 512 est trop petit et 1024 est probablement assez bon(certaines mises en garde s'appliquent) tandis que 2048 est définitivement sécurisé.
De plus, cependant, une attaque de précalcul a été démontrée de telle sorte que si vous connaissez les nombres premiers à l'avance, vous pouvez faire la majorité du travail de crackage d'un échange DH donné au préalable. C'est une tonne de calcul et prend beaucoup de temps pour calculer tous les vecteurs possibles pour un ensemble donné de nombres premiers, mais si un seul ensemble de nombres premiers est utilisé partout, alors il y a une incitation à dépenser du temps et de l'argent parce que le résultat être si largement utile.
Cela signifie que l'utilisation des mêmes nombres premiers que tout le monde est une responsabilité, car il est plus probable que le précalcul ait été effectué par votre attaquant. Vous voudrez donc probablement générer vos propres nombres premiers uniques pour vous tenir à l'écart du pool d'attaque. De plus, si vous êtes vous-même une cible si attrayante qu'un adversaire est prêt à dépenser des millions par mois pour vous attaquer (par exemple, des cibles de la taille de Facebook), la rotation régulière de vos primes peut être justifiée.
En ce qui concerne le coût et les efforts nécessaires pour effectuer ce précalcul, le travail pour les nombres premiers 512 bits peut être effectué par un individu dédié, pour les nombres premiers 1024 bits par un État-nation et les nombres premiers 2048 bits par une civilisation extraterrestre avancée peut-être.
La sécurité DH repose sur la dureté de Logarithme discret . Pour un nombre premier choisi au hasard p , cette dureté augmente avec la taille de p , en utilisant les algorithmes les plus connus. Par une chance semi-bizarre, il se trouve que le meilleur algorithme connu pour le logarithme discret a beaucoup en commun avec le meilleur algorithme connu pour la factorisation entière ( GNFS ) et le même coût de fonctionnement asymptotique. Ainsi, un module premier de 1024 bits pour DH fournit un niveau de sécurité qui est très approximativement équivalent à celui d'une clé RSA de 1024 bits.
Si nous regardons les détails, un module de 1024 bits est un peu plus fort qu'une clé RSA de 1024 bits, car grâce à GNFS-pour-logarithme discret et GNFS-pour-factorisation sont très similaires, leur étape finale (algèbre linéaire dans une énorme matrice) est plus difficile pour DL (le goulot d'étranglement est la taille de la matrice; pour la factorisation, les éléments de matrice sont des bits simples, tandis que pour DL ce sont des entiers modulo) p , c'est-à-dire mille fois plus grand. À ce jour, le RSA-1024 est toujours intact, et le DH 1024 bits encore plus.
Pourtant, casser la DH 1024 bits n'est pas complètement irréaliste; cela prendrait un montant non négligeable de dollars (milliards) et la construction d'une machine dédiée, à usage spécial, et le temps de fonctionnement seraient toujours comptés en mois, voire en années. Mais cela est possible sans invoquer l'aide de concepts de science-fiction (extraterrestres "très avancés" utiles) ou de théologie (divinités utiles). En ce sens, oui, vous devriez essayer d'utiliser un module plus grand.
Vous ne voulez pas utiliser un module surdimensionné car le coût d'utilisation du processeur augmente assez fortement avec cette taille (il devrait augmenter de façon quadratique, mais pour certaines implémentations, il est plutôt cubique, soit 4096 bits coûtant 8 fois plus que 2048 bits). 2048 bits sont très bien.
Un problème supplémentaire et assez vexant est qu'il existe des implémentations répandues de SSL qui ne prennent pas en charge le module DH supérieur à 1024 bits. Si vous utilisez OpenVPN, vous savez que le client et le serveur sont OpenVPN, vous ne devriez donc pas avoir de problèmes d'interopérabilité.
Le premier p et le générateur g ne sont pas secrets; ils peuvent également être partagés. Voir cette réponse pour plus de détails. Vous pouvez parfaitement les générer sur une machine et les utiliser sur une autre. Vous pouvez également configurer tous les appareils pour utiliser les mêmes paramètres DH; cela n'implique aucun problème de sécurité supplémentaire.
La génération des paramètres DH avec OpenSSL peut prendre beaucoup de temps car OpenSSL insiste, pour de bonnes raisons rationnelles, à générer des soi-disant "nombres premiers sûrs", c'est-à-dire un nombre premier p tel que (p-1)/2 est également un nombre premier. C'est exagéré et multiplie le temps de génération par un facteur énorme (plusieurs centaines). Ce qui est nécessaire pour DH est que p est premier et p = qr + 1 pour certains assez grands q ; un q de 256 bits serait déjà très bien. Passer à un "nombre premier sûr" (c'est-à-dire q de taille 1023 bits pour un 1024 bits p ) ne rend pas les choses plus sûres, malgré le nom (c'est un morceau de vieille tradition qui s'est transformé en mythe à cause d'une mauvaise terminologie).
Les "nombres premiers sûrs" ont un avantage de performance mineur (à l'utilisation, pas à la génération) en ce qu'ils permettent l'utilisation de g = 2 comme générateur; mais cet avantage est faible (il n'a d'importance que pour la moitié de l'échange de clés DH, et il est principalement annulé par des optimisations basées sur des fenêtres sur l'exponentiation modulaire).
Si vous vouliez vraiment générer des paramètres DH sur chaque appliance (ce qui n'est pas utile), alors vous pourriez ajouter le drapeau "-dsaparam" À la ligne de commande pour générer des paramètres DH sans insister pour avoir des "nombres premiers sûrs":
openssl dhparam -dsaparam -out dh2048.pem 2048
Cela devrait être beaucoup plus rapide. Mais générer les paramètres DH sur un PC et les coder en dur dans tous vos appareils est encore plus simple et sûr.