Si openssl utilise beaucoup de CPU alors il n'est pas bloqué en attendant "l'entropie". OpenSSL est en fait sain d'esprit à cet égard et utilise un PRNG cryptographiquement sécurisé 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 prenant soin d'utiliser pour le module un soi-disant "prime fort", ce qui est inutile pour la sécurité mais demande énormément plus d'effort de calcul. Un "premier fort" est un premier p tel que (p -1)/2 est aussi premier. L'algorithme de génération de nombres premiers ressemble à ceci :
- Générer un entier impair aléatoire p .
- Testez si p est premier. Sinon, bouclez.
- Tester si (p -1)/2 est premier. Sinon, bouclez.
Les entiers impairs aléatoires de 4096 bits ont une probabilité d'environ 1/2000 d'être premiers, et puisque les deux p et (p -1)/2 doit être premier, cela nécessitera en moyenne de générer et de tester la primalité d'environ 4 millions de nombres premiers impairs. Cela prendra forcément du temps.
En passant 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 2048 bits prend 1 heure en moyenne, la même chose une machine avec le même logiciel utilisera en moyenne 16 heures pour un module DH de 4096 bits. Ce ne sont que des 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 est d'ordre multiplicatif q ). C'est considérablement plus rapide car il n'est pas nécessaire 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 la DH sont tout aussi sûrs ; 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 2048 bits, qui est déjà très loin dans la "zone impossible à casser". Le module 4096 bits ralentira les calculs DH (ce qui n'est pas un réel 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 4 096 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 bien trop bon marché de toute façon.