Alimentation / dev / pool d'entropie aléatoire?

Thomas Pornin

2011-09-12 20:11:27 UTC

view on stackexchange narkive permalink

Vous devez utiliser / dev / urandom , pas / dev / random . Les deux différences entre / dev / random et / dev / urandom sont (je parle de Linux ici):

/ dev / random pourrait être théoriquement meilleur dans le contexte d'un algorithme sécurisé en théorie de l'information . C'est le genre d'algorithme qui est sécurisé contre la technologie d'aujourd'hui, ainsi que la technologie de demain, et la technologie utilisée par les extraterrestres, ainsi que le propre iPad de Dieu. Les algorithmes sécurisés en théorie de l'information sont protégés contre une puissance de calcul infinie. Inutile de dire que de tels algorithmes sont assez rares et si vous en utilisiez un, vous le sauriez. Aussi, c'est un " pourrait ": en interne, / dev / random utilise des fonctions de hachage conventionnelles, il y a donc de fortes chances qu'il ait de toute façon des faiblesses s'il est attaqué avec une puissance infinie (rien à craindre pour les attaquants basés sur Terre, cependant).
/ dev / urandom ne bloquera pas, tandis que / dev / random peut le faire. / dev / random maintient un compteur de "combien d'entropie il a encore" sous l'hypothèse que tous les bits qu'il a produits sont un bit d'entropie perdu. Le blocage induit des problèmes très réels, par ex. un serveur qui ne démarre pas après une installation automatisée car il bloque sur la création de sa clé de serveur SSH (oui, j'ai vu cela). / dev / urandom utilise un générateur de nombres pseudo-aléatoires cryptographiquement puissant pour qu'il ne se bloque jamais.

Donc, vous voulez utiliser / dev / urandom et arrêtez de vous soucier de cette activité d'entropie.

Maintenant, vous voudrez peut-être vous soucier de l'entropie si vous écrivez le programme d'installation Linux. L'astuce est que / dev / urandom ne bloque jamais, jamais, même quand il devrait: / dev / urandom est sécurisé tant qu'il a reçu suffisamment d'octets d'entropie initiale "depuis le dernier démarrage (32 octets aléatoires suffisent). Une installation Linux normale créera une graine aléatoire (à partir de / dev / random ) lors de l'installation, et l'enregistrera sur le disque. À chaque redémarrage, la graine sera lue, introduite dans / dev / urandom , et une nouvelle graine sera immédiatement générée (à partir de / dev / urandom ) pour la remplacer. Ainsi, cela garantit que / dev / urandom aura toujours suffisamment d'entropie initiale pour produire une alea cryptographiquement forte, parfaitement suffisante pour tout travail cryptographique banal, y compris la génération de mot de passe. Le seul point critique est lors de l'installation: l'installateur doit obtenir une certaine entropie de / dev / random , ce qui peut bloquer. Ce problème se produit également avec Live CD et d'autres variantes sans zone de stockage permanent en lecture-écriture. Dans ces situations, vous voudrez peut-être trouver une source d'entropie pour vous assurer que / dev / random sera bien alimenté et ne bloquera pas.

Le système d'exploitation lui-même, et plus précisément le noyau, est au bon endroit pour collecter l'entropie de l'événement matériel, car il gère le matériel. Il y a donc relativement peu de choses que vous pouvez utiliser pour l'entropie que le noyau n'utilise pas déjà. Une de ces sources restantes est les données de la webcam: une webcam, même face à un mur vide, produira des données avec un bruit thermique, et comme elle produit beaucoup de données, c'est un bon collecteur d'entropie. Il suffit donc de récupérer quelques images de la webcam, de les hacher avec une fonction de hachage sécurisée (SHA-256) et d'écrire cela dans / dev / urandom . C'est encore trop exagéré.

Je devrais vous dire d'avoir l'audace de suggérer que n'importe quelle divinité utiliserait un iPad. Tout le monde sait que Dieu utilise la Sainte PSP.

Votre dieu, peut-être. Mon dieu utilise un iPad, et en outre, il me l'a demandé.

Dieu n'a rien à voir avec ça, est-ce que personne ne voit le problème des gens qui démarrent à partir de machines virtuelles qui sont l'image théorique de "graine" fonctionnant sur une plage de pas si longtemps

Il convient de noter que pour tout système qui ne peut pas enregistrer l'état (stations de travail sans disque et routeurs sans disque inscriptible), / dev / random peut être privé d'entropie lors du premier démarrage. C'est normal pour Linux et tous les systèmes d'avoir initialement une faible quantité d'entropie au démarrage, mais cela est résolu en sauvegardant une graine aléatoire du dernier démarrage. Lorsque vous n'avez nulle part où enregistrer la graine, vous aurez un manque initial d'entropie. Il s'agit plutôt d'un cas secondaire, mais il est toujours important pour certains de connaître / dev / random.

Henri

2010-11-12 18:18:29 UTC

view on stackexchange narkive permalink

Vous pouvez l'alimenter avec le bruit blanc de votre puce audio, le cas échéant. Consultez cet article: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt

Vous * pourriez * faire cela, je suppose, mais pourquoi vous embêter? Il n'y a aucune raison de le faire. C'est inutile. Le noyau alimente déjà / dev / random et / dev / urandom avec une entropie suffisante à ces fins. Gagnez du temps pour quelque chose qui améliorera réellement la sécurité. Ou, pour le dire autrement, la question demandait si nous suggérions d'ajouter une entropie supplémentaire. La meilleure réponse est: non, il n'est pas nécessaire d'ajouter une entropie supplémentaire. Allez-y et utilisez / dev / urandom tel quel.

@D.W. D'après mon expérience avec les serveurs VPS, où il n'y a pas de véritable source d'entropie externe comme le clavier, la souris, etc., le pool d'entropie devient très faible et semble affecter des choses comme SSL. Cela peut encore fonctionner, mais on a l'impression que les choses avancent plus lentement. Après l'installation de haveged (voir une autre réponse ci-dessous), les choses se passaient beaucoup plus facilement. Peut-être qu'il y avait autre chose que j'aurais pu corriger, ou faire quelque chose de mal, mais je ne suis pas sûr que vous puissiez toujours compter sur votre noyau comme source d'entropie ...

Si je me souviens bien, quelques-unes des principales sources d'entropie sont des registres CPU qui sont modifiés très fréquemment à des valeurs raisonnablement aléatoires. Malheureusement, la virtualisation a un impact négatif sur le caractère aléatoire de ces registres en raison d'une planification plus prévisible des threads. Une solution est d'avoir un HRNG sur le serveur bare metal, puis de le mettre à disposition des VM.

@YoavAner, la raison pour laquelle vous rencontrez des problèmes est probablement parce que vous utilisez `/ dev / random`. Ne fais pas ça. Vous devez utiliser `/ dev / urandom`. Alors vous n'aurez pas ces problèmes - et ce sera sécurisé. Voir [Feeding / dev / random entropy pool?] (Http://security.stackexchange.com/q/89/971), [Un rand de / dev / urandom est-il sécurisé pour une clé de connexion?] (Http: // security.stackexchange.com/q/3936/971), [Pseudo Random Generator n'est pas initialisé à partir du (pool d'entropie)?] (http://security.stackexchange.com/q/14292/971). Version courte: utilisez / dev / urandom, pas / dev / random.

Merci @D.W. Je sais qu'urandom devrait résoudre ce problème, mais je ne suis pas sûr que tous les composants de mon système l'utilisent nécessairement. Par exemple, ce doit être un composant du serveur Web lighttpd, ou openssl ou qui-sait-quoi qui devenait drôle.

Merci, @YoavAner. J'ai mis en place une question distincte pour essayer d'identifier les changements de configuration nécessaires pour éviter cette situation: [Que dois-je configurer, pour m'assurer que mon logiciel utilise /dev/urandom? Often(http://security.stackexchange.com/ q / 14386/971).

Belle idée, et une liste de produits impressionnante, mais pour être honnête, je préfère quand même installer un composant (haveged) et ne pas avoir à m'en soucier. Je doute que l'entropie de Haveged soit moins sûre que celle d'urandom, mais je n'ai pas les connaissances ou l'expertise pour évaluer cela.

krempita

2010-12-11 16:10:58 UTC

view on stackexchange narkive permalink

Je connais le démon d'entropie audio et le hadge qui sont utilisés par démon haveged, essayez-les.

Ce sont inutiles. Le noyau alimente déjà / dev / random et / dev / urandom avec une entropie suffisante à ces fins.

@D.W. ça ne marche pas, ils ont fait quelque chose avec le noyau (Linux) donc ça ne fonctionne plus comme avant (s'épuise très vite) ...

@pootzko, Je ne le crois pas. Je soupçonne que vous interprétez mal ce que vous voyez. / dev / urandom ne s'épuise jamais.

tout d'abord, j'ai testé tout cela (surveiller l'entropie en utilisant différentes méthodes, donc lorsque l'entropie descend rapidement à des valeurs très faibles, cela signifie qu'elle s'est épuisée). deuxièmement, j'ai lu beaucoup de choses sur tout cela au moment de poser la question - le noyau a géré tout cela différemment il y a quelque temps. troisièmement - ce sont vos mots "/ dev / random a quelques problèmes: il bloque, il épuise le pool d'entropie" :))

+1 pour avoir. Grâce à une expérience personnelle principalement avec des serveurs virtuels, qui n'ont pas de clavier ou de souris attachés et qui ne peuvent pas non plus connecter un microphone facilement, haveged s'assure vraiment que tout se passe bien. À quel point son PRNG est-il fort, c'est difficile pour moi de le dire, mais cela semble raisonnablement sûr (en particulier par rapport au simple fait de compter sur urandom)

/ dev / urandom ne s'épuise pas, mais l'entropie de / dev / random peut l'être. Générer beaucoup de clés cryptographiques ou établir beaucoup de connexions SSL peut tous les deux gruger beaucoup d'entropie de / dev / random. Haveged ajoute au moins plus d'entropie à / dev / random, afin que vous n'ayez pas à vous fier au PRNG dans / dev / urandom.

@CoverosGene / dev / urandom et / dev / random utilisent le même PRNG.

@ViktorDahl / dev / blocs aléatoires à moins qu'il n'ait suffisamment d'entropie pour éviter de se fier uniquement au PRNG. Il utilise simplement le PRNG comme fonction de mixage.

Réponse la plus utile ici, je ne sais pas il y a 4 ans, mais aujourd'hui, il est très facile d'épuiser le pool de noyau sur les serveurs, surtout si vous voulez faire une sorte de résistance à la prédiction. Tellement très utile. J'ai fait quelques tests avec Haveged et c'est très bien, ça peut élever mon entropie à 0 de 1300 em en moins de 1 sec. Cherchant plus loin pour augmenter encore plus

spinkham

2010-11-20 03:03:35 UTC

view on stackexchange narkive permalink

La meilleure valeur que j'ai vue dans un dispositif d'aléa HW est la clé d'entropie simtec.
Possède un certain nombre de protections intégrées pour se protéger contre les pannes et les attaques. Par exemple, il exécute les tests aléatoires FIPS 140-2 sur chaque lot de 20 Ko, se fermant si un nombre statistiquement significatif de tests échouent, j'en ai obtenu un alors que je faisais beaucoup de génération de clés pour la recherche DNSSEC, et cela a considérablement accéléré mon travail. Il passe tous les tests les plus difficiles. (note, testez toujours vos flux aléatoires périodiquement, peu importe ce que le fournisseur vous dit ;-)

Le caractère aléatoire de HW est probablement excessif. / dev / urandom est parfaitement adéquat pour cette application, sans rien d'autre alimenté.

D.W.

2011-01-17 11:46:50 UTC

view on stackexchange narkive permalink

1) Vous n'avez plus besoin d'ajouter d'entropie à / dev / random , pour l'utiliser pour les mots de passe. Le système le fait déjà pour vous.

2) Pour générer un mot de passe aléatoire, il est préférable d'utiliser / dev / urandom , pas / dev / random . ( / dev / random a quelques problèmes: il bloque, il épuise le pool d'entropie d'une manière qui peut provoquer le blocage d'autres utilisateurs de / dev / random . / dev / urandom est la meilleure interface à usage général.)

3) Voici un script simple que j'utilise pour générer un mot de passe aléatoire. Vous pouvez l'utiliser.

  #! / Bin / sh # Créer un mot de passe de 48 bits (8 caractères, 6 bits par caractère) dd if = / dev / urandom count = 1 2> / dev / null | base64 | tête -1 | couper -c4-11

vos 1) et 2) sont opposés l'un à l'autre -> / dev / random épuise ... c'est exactement pourquoi j'ai demandé comment l'alimenter en plus ..

Vous confondez deux choses. / dev / random est * sécurisé * suffisant pour la génération de mot de passe sans entropie supplémentaire - donc alimenter des éléments dans / dev / random n'est pas nécessaire pour la sécurité, mais cela peut être nécessaire pour les performances. / dev / urandom est * également * suffisamment sécurisé pour les mots de passe, mais il n'a pas le problème de performances / dev / random, il devrait donc être préféré.

DUzun

2014-09-25 03:44:49 UTC

view on stackexchange narkive permalink

J'utilise une combinaison de sources de données et un bon algorithme de hachage pour générer des données aléatoires.

Sur un serveur Web, vous pouvez combiner les données du serveur (matériel, logiciel, performances), les données client (utilisateur- agent, request-time, cookie, variables d'URL, tout ce que vous pouvez collecter), certaines données externes (comme random.org), mélangez tout avec disons sha1 (mixed_data + time + some_secret_key) et vous obtenez des bits assez imprévisibles de données aléatoires.

Vous pouvez également envisager d'utiliser P2PEG pour collecter facilement l'entropie des clients et du serveur.

Nakedible

2010-12-12 02:59:27 UTC

view on stackexchange narkive permalink

Les mots de passe, s'ils sont courts, sont toujours craquables par force brute si la vitesse ou le nombre d'essais n'est pas limité. Si, d'un autre côté, les essais sont limités (par exemple, connexion interactive), même une petite quantité d'entropie fondamentalement incassable - le nombre d'essais requis devient très vite prohibitif.

Donc, il ne devrait y avoir aucun cas où obtenir une très bonne entropie pour les mots de passe importerait.

Alors utilisez simplement / dev / urandom, c'est plus que suffisant.

Les autres réponses données ici sont de bons commentaires sur la façon de conserver votre / dev / random est fourni avec suffisamment d'entropie, si vous en avez besoin.

Cette réponse n'est pas exacte dans la pratique ou est formulée de manière confuse. En pratique, on peut choisir des mots de passe avec une entropie suffisante pour qu'ils ne soient pas craquables par force brute. Ou, pour le dire autrement, dans la pratique, les attaquants sont toujours limités dans le nombre d'essais qu'ils peuvent faire, simplement par le temps limité dont ils disposent. Je suis d'accord avec le conseil d'utiliser / dev / urandom au lieu de / dev / random, mais la justification n'est pas correcte.

justin

2012-04-30 14:02:31 UTC

view on stackexchange narkive permalink

GUChaos.c récupère les nombres aléatoires de random.org, et les change à la volée grâce à un chiffrement de substitution avant d'alimenter / dev / random .

[Ne faites ** pas ** simplement confiance (appelons-les simplement) des «services» comme random.org à des fins de chiffrement.] (Http://crypto.stackexchange.com/q/1619/12164)

Buktop

2013-08-14 01:35:15 UTC

view on stackexchange narkive permalink

Il est étrange de voir un tas de recommandations d'utiliser / dev / urandom au lieu d'utiliser / dev / random cause quand / dev / random s'épuise alors / dev / urandom utilise la dernière entropie à plusieurs reprises, ce qui est fortement non sécurisé à long terme critique paramètres.

Vous devriez lire ces recommandations! Surtout [celui de Thomas Pornin] (http://security.stackexchange.com/questions/89/feeding-dev-random-entropy-pool/7074#7074). Vous ne comprenez pas l'entropie. La lecture depuis `/ dev / random` ou` / dev / urandom` n'épuise pas l'entropie (du moins pas sur une échelle qui importerait: la lecture de 2 ^ n bits épuise au plus n bits d'entropie).

Pensez-vous vraiment que l'entropie qu'un système d'exploitation peut obtenir est inépuisable?

"Générer une véritable entropie dans un ordinateur est assez difficile car rien, en dehors de la physique quantique, n'est aléatoire. Le noyau Linux utilise des activités clavier, souris, réseau et disque, avec un algorithme cryptographique (SHA1), pour générer des données pour le / dev / périphérique aléatoire. L'un des problèmes avec ceci est que l'entrée n'est pas constante, de sorte que le pool d'entropie du noyau peut facilement devenir vide. Le périphérique / dev / random est appelé un "périphérique bloquant". Cela signifie que si le pool d'entropie est vide, les applications essayer d'utiliser / dev / random devra attendre indéfiniment jusqu'à ce que quelque chose remplisse le pool. "

"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 doit convenir aux utilisations qui nécessitent un caractère aléatoire de très haute qualité, comme un pad ponctuel ou génération de clé. Lorsque le pool d'entropie est vide, les lectures de / dev / random seront bloquées jusqu'à ce que du bruit environnemental supplémentaire soit collecté. "

"Une lecture depuis le périphérique / dev / urandom ne bloquera pas l'attente d'une plus grande entropie. 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. . "

En pratique, oui. Une fois que vous avez rempli dans la piscine entropie une fois, il faudrait plus que la durée de vie du matériel pour l'appauvrir.

Gardez à l'esprit que / dev / random et / dev / urandom ne fournissent que 160 bits d'entropie pour une requête.

Déterminez maintenant combien de temps il faut pour épuiser 160 bits d'entropie.

Nous pouvons mélanger ces bits par hachage (par exemple) et produire de manière relativement sûre 2 ^ 48 blocs de 512 bits de longueur. Cependant, je voudrais recommander d'utiliser 128 bits d'entropie pour produire une seule clé RSA (3072 bits) et actualiser l'entropie pour générer la clé suivante. Bien sûr, la mise en œuvre coûte et a du sens si vous cachez quelque chose qui coûte au moins le même prix.