Ai-je compris / dev / urandom?
J'ai lu sur /dev/urandom, et pour autant que je sache, /dev/random crée des nombres cryptographiquement aléatoires en tirant parti de plusieurs événements comme la synchronisation des paquets réseau, etc. Cependant, ai-je bien compris que /dev/urandom utilise un PRNG, avec un nombre de /dev/random? Ou utilise-t-il simplement /dev/random tant qu'il y a des bits - et quand ils s'épuisent, cela revient à certains PRNG avec une graine recueillie d'où?
À partir de la page de manuel urandom:
Le générateur de nombres aléatoires collecte le bruit environnemental des pilotes de périphériques et d'autres sources dans un pool d'entropie. Le générateur conserve également une estimation du nombre de bits de bruit dans le pool d'entropie. À partir de ce pool d'entropie, des nombres aléatoires sont créés.
Lors de la lecture, le périphérique/dev/random ne renverra que des octets aléatoires dans le nombre estimé de bits de bruit dans le pool d'entropie./dev/random devrait convenir à des utilisations qui nécessitent un caractère aléatoire de très haute qualité, comme un pad unique ou la génération de clés. Lorsque le pool d'entropie est vide, les lectures de/dev/random bloqueront jusqu'à ce que du bruit environnemental supplémentaire soit collecté.
ne lecture du périphérique/dev/urandom ne bloquera pas l'attente d'une entropie supplémentaire. Par conséquent, s'il n'y a pas suffisamment d'entropie dans le pool d'entropie, les valeurs renvoyées sont théoriquement vulnérables à une attaque cryptographique sur les algorithmes utilisés par le pilote. La connaissance de la façon de procéder n'est pas disponible dans la littérature non classifiée actuelle, mais il est théoriquement possible qu'une telle attaque puisse exister. Si cela pose problème dans votre application, utilisez plutôt/dev/random.
les deux utilisent un PRNG, bien que l'utilisation de données environnementales et d'un pool d'entropie rende astronomiquement beaucoup plus difficile de casser le PRNG, et impossible sans collecter également les mêmes données environnementales.
En règle générale, sans matériel coûteux spécialisé qui collecte des données, par exemple, des événements quantiques, il n'existe pas de véritable générateur de nombres aléatoires (c'est-à-dire un RNG qui génère un nombre vraiment imprévisible); bien qu'à des fins cryptographiques,/dev/random ou/dev/urandom suffira (la méthode utilisée est pour un CPRNG, générateur de nombres pseudo-aléatoires cryptographiques).
Le pool d'entropie et la lecture de blocage de/dev/random sont utilisés comme garde-fou pour garantir l'impossibilité de prédire le nombre aléatoire; si, par exemple, un attaquant a épuisé le pool d'entropie d'un système, il est possible, bien que très peu probable avec la technologie d'aujourd'hui, qu'il puisse prédire la sortie de/dev/urandom qui n'a pas été réamorcée depuis longtemps (bien que faisant cela obligerait également l'attaquant à épuiser la capacité du système à collecter plus d'entropies, ce qui est également improbable astronomiquement).
En fait, ce dont vous avez besoin dans la pratique est ce que /dev/urandom De FreeBSD fournit: il lira une graine initiale de longueur suffisante à partir de /dev/random, Puis utilisera un PRNG. Ainsi, il peut bloquer initialement (juste après le démarrage du système) mais une fois qu'il a rassemblé suffisamment d'entropie, il ne se bloque jamais. Cela fournit le niveau d'aléatoire requis par la plupart des protocoles cryptographiques, sans bloquer indûment.
Le /dev/urandom De Linux est similaire sauf qu'il ne se bloquera jamais, et peut donc risquer de retourner un caractère aléatoire de faible qualité s'il est utilisé juste après le démarrage. D'un autre côté, /dev/random Peut se bloquer même longtemps après le démarrage, ce qui est également un problème. J'ai souvent vu des serveurs caler mystérieusement, car certains logiciels insistaient pour utiliser /dev/random, Et le serveur sans clavier n'obtenait pas assez d'entropie.
La distribution Linux habituelle enregistre à l'arrêt une graine aléatoire obtenue à partir de /dev/urandom, Et la réinjecte au prochain démarrage, garantissant ainsi la qualité de l'aléatoire fourni par /dev/urandom. Ce n'est que lors de l'installation du système d'exploitation que la qualité cryptographique devient un problème, et ce n'est généralement pas parce que l'installation implique un certain nombre d'interactions avec l'être humain qui effectue l'installation, produisant des hordes d'entropie.
Pour résumer, sous Linux et FreeBSD, vous devez utiliser /dev/urandom, Pas /dev/random.
Citant ici
/dev/randomse bloquera une fois le pool d'entropie épuisé. Il restera bloqué jusqu'à ce que des données supplémentaires aient été collectées auprès des sources d'entropie disponibles. Cela peut ralentir la génération de données aléatoires.
/dev/urandomne bloquera pas. Au lieu de cela, il réutilisera le pool interne pour produire plus de bits pseudo-aléatoires.
/dev/urandom est mieux utilisé lorsque:
- Vous voulez juste un gros fichier avec des données aléatoires pour une sorte de test.
- Vous utilisez la commande
ddpour effacer les données d'un disque en le remplaçant par des données aléatoires. - Presque partout ailleurs où vous n'avez pas vraiment de bonnes raisons d'utiliser
/dev/randomau lieu.
/dev/random est probablement le meilleur choix lorsque:
- L'aléatoire est essentiel à la sécurité de la cryptographie dans votre application - blocs ponctuels, génération de clés.