À quoi sert l'option Java.security.egd?
Dans un projet sur lequel je travaille, l'application est lancée à l'aide d'une commande similaire à celle-ci:
Java -Djava.security.egd=file:/dev/urandom -jar app.jar
Je n'ai jamais vu le Java.security.egd option avant. En cherchant un peu, il semble utilisé pour configurer la génération de nombres aléatoires dans une application Java.
Est ce juste? Quand est-il censé être appliqué?
Les applications Java peuvent et doivent utiliser la classe Java.security.SecureRandom pour produire des valeurs aléatoires cryptographiquement fortes en utilisant un générateur de nombres pseudo-aléatoires cryptographiquement fort ( CSPRNG ). Les implémentations JDK standard de Java.util.Random classe n'est pas considérée comme cryptographiquement forte.
Les systèmes d'exploitation de type Unix ont /dev/random, un fichier spécial qui sert des nombres pseudo-aléatoires accédant au bruit environnemental collecté à partir des pilotes de périphériques et d'autres sources. Cependant, il bloque s'il y a moins d'entropie disponible que demandé; /dev/urandom ne bloque généralement jamais, même si la valeur de départ du générateur de nombres pseudo-aléatoires n'a pas été complètement initialisée avec l'entropie depuis le démarrage. Il existe toujours un 3e fichier spécial, /dev/arandom qui bloque après le démarrage jusqu'à ce que la graine ait été correctement initialisée avec suffisamment d'entropie, puis ne bloque plus jamais.
Par défaut, la JVM amorce la classe SecureRandom en utilisant /dev/random, donc votre Java peut bloquer de manière inattendue. L'option -Djava.security.egd=file:/dev/./urandom dans l'invocation de ligne de commande utilisée pour démarrer le processus Java indique à la JVM d'utiliser /dev/urandom au lieu.
L'extra /./ semble inciter la JVM à utiliser le algorithme SHA1PRNG qui utilise SHA-1 comme base du PRNG (générateur de nombres pseudo-aléatoires). Il est plus fort que l'algorithme NativePRNG utilisé lorsque /dev/urandom est spécifié.
Enfin, il existe un mythe selon lequel /dev/urandom est un générateur de nombres pseudo aléatoires, un PRNG, tandis que /dev/random est un "vrai" générateur de nombres aléatoires. Ce n'est tout simplement pas vrai, les deux /dev/random et /dev/urandom sont alimentés par le même CSPRNG (générateur de nombres pseudo-aléatoires cryptographiquement sécurisé). Seul le comportement lorsque leur pool respectif manque d'entropie, selon certaines estimations, diffère: /dev/random bloque, tandis que /dev/urandom ne fait pas.
Qu'en est-il de l'entropie faible? Cela n'a pas d'importance.
Il s'avère que "regarder au hasard" est l'exigence de base pour beaucoup de nos blocs de construction cryptographiques. Et si vous prenez la sortie d'un hachage cryptographique, il doit être impossible de la distinguer d'une chaîne aléatoire afin que les chiffrements l'acceptent. C'est la raison d'utiliser l'algorithme SHA1PRNG, car il utilise une fonction de hachage et un compteur, ainsi qu'une graine.
Quand est-il censé être appliqué?
Je dirais toujours.
Sources:
https://Gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom
Ceci est lié à la différence de linux /dev/random et /dev/urandom générateur de nombres aléatoires.
Tiré de cela lien
Java Bug 6202721 indique que Java.security.SecureRandom utilise/dev/random plutôt que/dev/urandom même si/dev/urandom est spécifié car à l'époque (vers 2004)/dev/urandom n'était pas fonctionner correctement. Le bogue n'a jamais été inversé maintenant que/dev/urandom fonctionne assez bien. Par conséquent, vous devez le simuler en masquant le paramètre en utilisant /dev/./urandom pour forcer l'utilisation de SHA1PRNG plutôt que/dev/random.
Pour répondre à ta question
Quand est-il censé être appliqué?
Sur la base du lien ci-dessus, c'est quelque chose d'unique à Java versions 5 et suivantes qui résulte de problèmes avec/dev/urandom sur les systèmes Linux en 2004.
Ce n'est plus nécessaire si vous utilisez JDK 8 ou supérieur
Le problème a été résolu par Java et voici quelques liens
Contour
SHA1PRNG et NativePRNG ont été corrigés pour respecter correctement les propriétés de la source de départ SecureRandom dans le fichier Java.security. (La solution de contournement obscure utilisant file: /// dev/urandom et file:/dev /./ urandom n'est plus nécessaire.)
Pour plus d'informations (recherchez aléatoire dans la page):
https://docs.Oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html
https://www.Oracle.com/technetwork/Java/javase/8-whats-new-2157071.html