Les paramètres Diffie Hellman calculent toujours après 24 heures
J'ai une nouvelle installation d'Arch Linux sur un modèle RaspberryPi B. Je configure OpenVPN et j'utilise easy-rsa avec OpenSSL 1.0.2d pour générer les clés et certificats initiaux. Tout s'est bien passé jusqu'à ce que je coure ./build-dh (script ici ). C'était 24 heures plus tard quand j'ai écrit ceci .
J'ai déjà configuré OpenVPN sur d'autres appareils et le même RaspberryPi, mais sous Raspbian. Et je ne me souviens pas que cette commande ait pris autant de temps. La dernière fois, j'ai utilisé une clé de 2048 bits et cela a pris environ une heure. Maintenant, j'essaie avec une clé de 4096 bits et cela fait plus d'une journée. En fait, cela fait encore 12 heures que j'ai réinitialisé tous mes paramètres, activé le générateur de nombres aléatoires du matériel de build-it et essayé à nouveau. Mais c'est toujours en cours.
cat /proc/sys/kernel/random/entropy_avail renvoie des valeurs comprises entre 3000 et 3100.
Quelqu'un at-il une expérience antérieure avec cela? Comment puis-je vérifier qu'il ne s'exécute pas en boucle?
Si openssl utilise beaucoup de CPU, il n'est pas bloqué en attendant "entropie". OpenSSL est en fait sain d'esprit à cet égard, et utilise un PRNG sécurisé cryptographiquement pour étendre une graine initiale en autant de bits que nécessaire.
Lorsque vous utilisez dhparam, OpenSSL génère non seulement des paramètres DH; il veut aussi affirmer son statut social en veillant à utiliser pour le module un soi-disant "fort premier", ce qui est inutile pour la sécurité mais nécessite beaucoup plus d'efforts de calcul. Un "fort premier" est un premier p tel que ( p - 1)/2 est également premier. L'algorithme de première génération ressemble à ceci:
- Générez un entier impair aléatoire p .
- Testez si p est premier. Sinon, boucle.
- Testez si ( p - 1)/2 est premier. Sinon, boucle.
Les entiers impairs aléatoires de 4096 bits sont des probabilités d’environ 1/2000 d’être premiers, et puisque p et ( p - 1)/2 doit être premier, il faudra en moyenne générer et tester la primauté sur 4 millions de nombres premiers impairs. Cela ne peut que prendre du temps.
Lorsque vous passez de 2048 bits à 4096 bits, la densité des nombres premiers forts est divisée par 4, et les tests de primalité seront également environ 4 fois plus lents, donc si la génération d'un module DH de 2048 bits prend 1 heure en moyenne, la même chose La machine avec le même logiciel utilisera en moyenne 16 heures pour un module DH de 4096 bits. Ce ne sont que moyennes ; chaque génération individuelle peut être plus rapide ou plus lente, selon votre chance.
La solution raisonnable serait d'ajouter le -dsaparam option.
openssl dhparam -dsaparam -out /etc/ssl/private/dhparam.pem 4096
Cette option demande à OpenSSL de produire des paramètres DH "de type DSA" ( p est tel que p - 1 est un multiple d'un plus petit nombre premier q , et le générateur a un ordre multiplicatif q ). Ceci est considérablement plus rapide car il n'a pas besoin d'imbriquer les tests de primalité, et donc seuls des milliers, et non des millions, de candidats seront générés et testés.
Pour autant que les universitaires le sachent, les paramètres de type DSA pour DH sont également sécurisés; il n'y a aucun avantage réel à utiliser des "nombres premiers forts" (la terminologie est traditionnelle et n'implique pas réellement une force supplémentaire).
De même, vous pouvez également utiliser un module de 2048 bits, qui est déjà très loin dans la zone "ne peut pas le casser". Le module de 4096 bits ralentira les calculs DH (ce qui n'est pas un vrai problème pour un VPN; ceux-ci ne se produisent qu'au début de la connexion), mais n'améliorera pas réellement la sécurité.
Dans une certaine mesure, un module de 4096 bits peut séduire les auditeurs, mais il est peu probable que les auditeurs soient très impressionnés par un Raspberry-Pi, qui est de toute façon beaucoup trop bon marché.