Comment résoudre un problème de performance avec Java SecureRandom?

Question

Si vous voulez un nombre aléatoire cryptographiquement fort en Java, utilisez SecureRandom. Malheureusement, SecureRandom peut être très lent. S'il utilise / dev / random sous Linux, il peut bloquer l'attente d'une entropie suffisante pour se développer. Comment évitez-vous la pénalité de peformance?

Quelqu'un at-il utilisé Uncommon Maths comme solution à ce problème?

Quelqu'un peut-il confirmer que ce problème de performances a été résolu dans JDK 6?

Answer 1

Vous devriez pouvoir sélectionner le fichier / dev / urandom plus rapide mais légèrement moins sécurisé sous Linux en utilisant:

 -Djava.security.egd=file:/dev/urandom
 

Toutefois, cela ne fonctionne pas avec Java 5 et les versions ultérieures ( bogue Java 6202721 ). La solution suggérée consiste à utiliser:

 -Djava.security.egd=file:/dev/./urandom
 

(notez le supplément '/./')

Answer 2

Si vous voulez un vrai aléatoire de données, puis, malheureusement, vous avez à attendre. Cela comprend les semences pour une SecureRandom PRNG. Rare Mathématiques peuvent pas recueillir des vrais aléatoire de la base de données plus rapide que SecureRandom, bien qu'il puisse se connecter à internet pour télécharger des semences de données à partir d'un site web particulier. Ma conjecture est qu'il est peu probable d'être plus rapide que /dev/random où c'est disponible.

Si vous voulez un PRNG, faire quelque chose comme ceci:

SecureRandom.getInstance("SHA1PRNG");

Ce que les chaînes de caractères sont pris en charge dépend de la SecureRandom fournisseur SPI, mais vous pouvez les énumérer, à l'aide de la Sécurité.getProviders() et le Fournisseur.la méthode getService().

Le soleil est friand de SHA1PRNG, il est donc largement disponibles. Il n'est pas particulièrement rapide que PRNGs aller, mais PRNGs sera juste à croquer des nombres, ce n'est pas bloquant pour la mesure physique de l'entropie.

L'exception est que si vous ne faites pas appel setSeed() avant d'obtenir les données, puis le GÉNÉRATEUR va de la graine elle-même une fois le premier moment de l'appel à next() ou nextBytes(). Il sera généralement faire cela en utilisant une quantité assez faible de vrai aléatoire des données à partir du système. Cet appel peut bloquer, mais rendra votre source de nombres aléatoires beaucoup plus sécurisé que n'importe quelle variante de "hachage à l'heure actuelle avec le PID, ajouter 27, et espérer pour le mieux". Si vous avez besoin de nombres aléatoires pour un jeu, même si, ou si vous voulez que le flux soit reproductible à l'avenir à l'aide de la même semence à des fins de test, une insécurité de semences est toujours utile.

Answer 3

Sur Linux, le défaut de mise en œuvre de SecureRandom est "NativePRNG" (code source ici), qui tend à être très lent. Sur Windows, la valeur par défaut est "SHA1PRNG", qui comme d'autres l'ont souligné, vous pouvez également l'utiliser sous Linux, si vous le spécifier explicitement.

"NativePRNG" diffère de la "SHA1PRNG" et Uncommons Maths' AESCounterRNG en ce qu'il reçoit en permanence de l'entropie du système d'exploitation (par la lecture à partir de /dev/urandom). Les autres PRNGs de ne pas acquérir de l'entropie supplémentaire après le semis.

AESCounterRNG est d'environ 10x plus rapide que le "SHA1PRNG", qui IIRC est lui-même deux ou trois fois plus rapide que le "NativePRNG".

Si vous avez besoin d'un plus rapide PRNG qui acquiert l'entropie après l'initialisation, voir si vous pouvez trouver une implémentation Java de Fortuna. Le noyau GÉNÉRATEUR d'une Fortuna de mise en œuvre est identique à celle utilisée par AESCounterRNG, mais il y a aussi un système sophistiqué de l'entropie de mise en commun et de réamorçage automatique.

Answer 4

Si vous voulez vraiment "fort niveau de chiffrement" aléatoire, alors vous avez besoin d'une forte source d'entropie. /dev/random est lent, car il n'a plus à attendre les événements du système pour recueillir de l'entropie (la lecture du disque, les paquets réseau, le mouvement de la souris, les touches, etc.).

Une solution plus rapide est un matériel générateur de nombre aléatoire. Vous pouvez déjà avoir un intégré à votre carte mère; découvrez le hw_random de la documentation pour obtenir des instructions pour savoir si vous l'avez, et comment l'utiliser. Le rng-tools package comprend un démon qui va nourrir le matériel généré par l'entropie dans /dev/random.

Si un HRNG n'est pas disponible sur votre système, et vous êtes prêt à sacrifier l'entropie de la force pour la performance, vous voulez des graines d'une bonne PRNG avec des données à partir de /dev/random, et de laisser le PRNG faire le gros du travail. Il y a plusieurs NIST approuvé PRNG répertorié dans SP800-90 qui sont simples à mettre en œuvre.

Answer 5

Le problème que vous l'avez mentionné à propos de /dev/random est pas avec le SecureRandom algorithme, mais avec la source de l'aléatoire qu'il utilise. Les deux sont orthogonaux. Vous devriez savoir laquelle des deux est vous ralentir.

UncommonMaths page que vous avez lié mentionne explicitement qu'ils ne traitent pas la source de l'aléatoire.

Vous pouvez essayer différentes JCE de fournisseurs, tels que BouncyCastle, pour voir si leur mise en œuvre de SecureRandom est plus rapide.

Une brève recherche révèle également des correctifs Linux que de remplacer la valeur par défaut de mise en œuvre avec Fortuna. Je ne sais pas beaucoup plus à ce sujet, mais vous êtes les bienvenus pour enquêter.

Je devrais aussi mentionner que, même s'il est très dangereux d'utiliser un mal mises en œuvre SecureRandom algorithme et/ou de l'aléatoire de la source, vous pouvez lancer votre propre entreprise criminelle commune Fournisseur avec une mesure de mise en œuvre de SecureRandomSpi. Vous aurez besoin de passer par un processus avec le Soleil pour obtenir votre fournisseur signé, mais c'est en fait assez simple; ils ont juste besoin de vous pour faxer un formulaire indiquant que vous êtes au courant de la NOUS les restrictions à l'exportation sur des bibliothèques de chiffrement.