Selon la documentation , les différents algorithmes utilisés par SecureRandom sont, par ordre de préférence:
- Sur la plupart des systèmes * NIX
- NatifPRNG
- SHA1PRNG
- NatifPRNGBlocking
- NatifPRNGNonBlocking
- Sur les systèmes Windows
- SHA1PRNG
- Windows-PRNG
Depuis que vous avez posé des questions sur Linux, j'ignore l'implémentation de Windows, ainsi que SunPKCS11 qui n'est vraiment disponible que sur Solaris, sauf si vous l'avez installé vous-même - et alors vous ne poseriez pas cette question.
Selon cette même documentation, ce que ces algorithmes utilisent sont
SHA1PRNG
L'amorçage initial est actuellement effectué via une combinaison d'attributs système et du périphérique de collecte d'entropie java.security.
NativePRNG
nextBytes()
utilise des /dev/urandom
generateSeed()
utilisations/dev/random
NativePRNGBlocking
nextBytes()
et generateSeed()
utilisation/dev/random
NativePRNGNonBlocking
nextBytes()
et generateSeed()
utilisation/dev/urandom
Cela signifie que si vous utilisez SecureRandom random = new SecureRandom()
, il descend dans cette liste jusqu'à ce qu'il en trouve une qui fonctionne, qui sera généralement NativePRNG. Et cela signifie qu'il se lance à partir de /dev/random
(ou l'utilise si vous générez explicitement une graine), puis utilise/dev/urandom
pour obtenir les octets suivants, entiers, doubles, booléens, what-have-yous.
Puisqu'il /dev/random
bloque (il bloque jusqu'à ce qu'il ait suffisamment d'entropie dans le pool d'entropie), cela peut nuire aux performances.
Une solution à cela consiste à utiliser quelque chose comme avoir pour générer suffisamment d'entropie, une autre solution utilise à la /dev/urandom
place. Bien que vous puissiez définir cela pour l'ensemble de jvm, une meilleure solution consiste à le faire pour cette instance spécifique de SecureRandom
, en utilisant SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking")
. Notez que cette méthode peut lever une NoSuchAlgorithmException si NativePRNGNonBlocking, alors soyez prêt à revenir à la valeur par défaut.
SecureRandom random;
try {
random = SecureRandom.getInstance("NativePRNGNonBlocking");
} catch (NoSuchAlgorithmException nsae) {
random = new SecureRandom();
}
Notez également que sur d'autres systèmes * nix, /dev/urandom
peut se comporter différemment .
Est-ce /dev/urandom
assez aléatoire?
La sagesse conventionnelle veut que ce /dev/random
soit assez aléatoire. Cependant, certaines voix diffèrent. Dans «La bonne façon d'utiliser SecureRandom» et «Mythes sur / dev / urandom» , on soutient que /dev/urandom/
c'est tout aussi bien.
Les utilisateurs de la pile de sécurité de l'information sont d'accord avec cela . Fondamentalement, si vous devez demander, /dev/urandom
c'est bien pour votre objectif.