Pourquoi mon / dev / random est-il si lent lorsque j'utilise dd?


29

J'essaie d'effacer de manière semi-sécurisée un tas de disques durs. Ce qui suit fonctionne à 20-50Mb / s

dd if=/dev/zero of=/dev/sda

Mais

dd if=/dev/random of=/dev/sda 

semble ne pas fonctionner. Aussi quand je tape

dd if=/dev/random of=stdout

Cela ne me donne que quelques octets, peu importe ce que je passe pour bs = et count =

Suis-je en train d'utiliser / dev / random mal? Quelles autres informations dois-je rechercher pour faire avancer ce dépannage? Y a-t-il une autre façon de le faire avec un script ou quelque chose comme

makeMyLifeEasy | dd if=stdin of=/dev/sda

Ou quelque chose comme ça...


1
Juste une note: à moins que vous ne soupçonniez la CIA de poursuivre vos données, un seul remplacement avec des zéros (/ dev / zero) est probablement suffisant. Voir par exemple superuser.com/questions/215852/… pour une discussion.
sleske

Quant à savoir pourquoi la lecture de /dev/randomne renvoie que quelques octets, voir superuser.com/a/712515/139307
mklement0

Réponses:


42

Les deux /dev/randomet /dev/urandomutilisent une «piscine entropique». Lorsque le pool est épuisé, /dev/randomattend qu'il se remplisse, ce qui nécessite de surveiller le comportement du système (saisie au clavier, mouvement de la souris, etc.), alors /dev/urandomqu'il continuera à vous fournir des données pseudo-aléatoires. /dev/randomest théoriquement de meilleure qualité, mais /dev/urandomest presque certainement assez bonne pour vos besoins. (Mais même /dev/urandomest probablement plus lent que certaines autres méthodes. Un générateur plus rapide mais de qualité inférieure est probablement assez bon pour effacer les disques durs. Il n'est pas clair qu'un attaquant gagnerait à connaître la séquence qui va être générée, ou que les nombres aléatoires sont meilleurs à cet effet qu'une séquence comme 0, 1, 2, 3, 4, ....)

Citant la random(4)page de manuel:

Si vous ne savez pas si vous devez utiliser /dev/randomou /dev/urandom, alors vous voudrez probablement utiliser ce dernier. En règle générale, /dev/urandomdoit être utilisé pour tout sauf les clés GPG / SSL / SSH à longue durée de vie.

MISE À JOUR : La page de manuel `random (4) a été mise à jour depuis que j'ai écrit cela. Il dit maintenant:

L' /dev/randominterface est considérée comme une interface héritée, et /dev/urandomest préférée et suffisante dans tous les cas d'utilisation, à l'exception des applications qui nécessitent un caractère aléatoire au début du démarrage; pour ces applications, getrandom(2)doit être utilisé à la place, car il se bloquera jusqu'à ce que le pool d'entropie soit initialisé.

Voir aussi " Mythes sur / dev / urandom " par Thomas Hühn.

Mais /dev/urandom, même s'il ne se bloque pas, il est probable qu'il soit trop lent si vous souhaitez générer d'énormes quantités de données. Prenez quelques mesures sur votre système avant de l'essayer.

EDIT: Ce qui suit est une digression sur les «vrais» nombres aléatoires par rapport aux nombres pseudo-aléatoires. Si tout ce qui vous intéresse est une réponse pratique à la question, vous pouvez arrêter de lire maintenant.

Il me semble que les revendications (y compris dans d'autres réponses ici) /dev/randomimplémentent un "vrai" générateur de nombres aléatoires, par opposition à un générateur de nombres pseudo-aléatoires (PRNG). Par exemple, l'article Wikipedia fait une telle affirmation. Je ne pense pas que ce soit correct. Il y a une discussion à ce sujet ici qui se réfère aux générateurs de nombres aléatoires matériels, mais je ne vois aucune preuve qui /dev/randomutilise généralement un tel appareil, ou que les ordinateurs typiques ont même un tel appareil. Ils diffèrent des PRNG comme la rand()fonction C en ce qu'ils ne sont pas déterministes, car ils récoltent l'entropie à partir de sources pratiquement imprévisibles.

Je dirais qu'il existe trois classes de générateurs de nombres "aléatoires":

  1. Des PRNG déterministes, comme la rand()fonction de C , qui utilisent un algorithme pour générer des séquences répétables qui ont (plus ou moins) les propriétés statistiques d'une séquence vraiment aléatoire. Ceux-ci peuvent être assez bons pour les jeux (étant donné un bon moyen de les semer), et sont nécessaires pour les applications qui nécessitent une répétabilité, mais ils ne conviennent pas à la cryptographie.

  2. Les générateurs aiment /dev/randomet /dev/urandomqui récoltent l'entropie d'une source pratiquement imprévisible comme l'activité d'E / S (c'est pourquoi frapper sur le clavier ou déplacer la souris peut entraîner la /dev/randomproduction de plus de données). Il n'est pas clair (pour moi) si ceux-ci répondent à la définition d'un PRNG (j'ai vu des définitions qui disent qu'un PRNG est déterministe), mais ce ne sont pas non plus de véritables générateurs de nombres aléatoires.

  3. Générateurs de nombres aléatoires matériels qui sont physiquement imprévisibles même avec une connaissance complète de leur état initial, et qui utilisent en outre des techniques mathématiques pour garantir les bonnes propriétés statistiques.


2
Même / dev / urandom est un peu lent si vous devez remplir d'énormes quantités d'espace disque (comme des partitions entières, avant de créer des systèmes de fichiers cryptés). Cela devrait être considéré comme un petit ajout à l'excellente réponse et à l'explication détaillée.
vtest

Comme vous ne pouvez pas calculer / dériver / créer / ... plus d'un bit d'entropie à partir d'un bit aléatoire, tout ce qui génère / génère plus de bits `` aléatoires '' qu'il n'en a reçu en entrée est par définition pseudo-aléatoire au mieux. Par conséquent, /dev/urandomest clairement pseudo-aléatoire. /dev/randomdiffère en ce qu'il essaie de faire une estimation prudente de l'entropie de son entrée et ne produit pas plus d'entropie qu'il ne le pense (le pense). Cela est indépendant de la présence d'un appareil TRNG dédié, car la véritable entropie peut également être obtenue à partir d'événements indépendants de toute nature, comme le clavier ou le réseau IO en fonction du temps.
JimmyB

13

/dev/randomest une source d'entropie véritable, d'octets vraiment aléatoires. En tant que tel, il a besoin d'une source de hasard. Vous pouvez «utiliser» le caractère aléatoire en y lisant. Il vous donnera tout le caractère aléatoire qu'il a, puis bloquera jusqu'à ce qu'il en obtienne plus. Vous êtes probablement assis là à attendre, et la machine reçoit très peu de nouveaux aléas, et elle attend juste.

/dev/randompour une cryptographie vraiment aléatoire, un caractère aléatoire de haute qualité. En tant que tel, il s'agit d'une surcharge pour l'écrasement d'un lecteur de disque. L'écriture de /dev/zeroquelques fois est très bien. Ou vous pouvez écrire à partir de /dev/urandom, qui ne bloquera pas et donnera des nombres pseudo-aléatoires quand il ne sera plus vraiment aléatoire.


10
Non, /dev/randomne génère pas "d'octets vraiment aléatoires". Il génère des octets pseudo- aléatoires de meilleure qualité que /dev/urandomne le fait.
Keith Thompson

7

Sous Linux / dev / random est un fichier spécial qui sert des nombres pseudo aléatoires de haute qualité. Cette implémentation collecte l'entropie des événements provenant des interruptions du clavier, de la souris, du disque et du système. (reportez - vous à ce document) Ainsi, en l'absence de tels événements, le pool d'entropie est vide, les lectures de / dev / random se bloqueront jusqu'à ce que du bruit environnemental supplémentaire soit collecté. Cela explique votre problème. Pour remplir le pool d'entropie, vous pouvez appuyer sur les touches du clavier.

D'un autre côté, un générateur de nombres vraiment aléatoires utilise un générateur de nombres aléatoires matériel qui génère des nombres aléatoires à partir de processus physiques. Ces processus incluent des phénomènes microscopiques qui génèrent un signal de «bruit» statistiquement aléatoire de bas niveau, comme le bruit thermique ou d'autres phénomènes physiques. Ces processus sont, en théorie, totalement imprévisibles et les affirmations d'imprévisibilité de la théorie sont soumises à des tests expérimentaux.

Un générateur matériel de nombres aléatoires se compose généralement d'un transducteur pour convertir certains aspects des phénomènes physiques en un signal électrique, un amplificateur et d'autres circuits électroniques pour augmenter l'amplitude des fluctuations aléatoires à un niveau macroscopique, et un certain type de convertisseur analogique-numérique pour convertir la sortie en un nombre numérique, souvent un simple chiffre binaire 0 ou 1. En échantillonnant à plusieurs reprises le signal variant de façon aléatoire, une série de nombres aléatoires est obtenue.

Le générateur de nombres aléatoires matériels collecte le bruit environnemental des pilotes de périphériques et d'autres sources dans un 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. Cela explique votre problème.

Certaines implémentations de Hardware RNG sont expliquées dans la documentation du noyau et les informations sur un périphérique .

Une contrepartie de / dev / random est / dev / urandom (source aléatoire "non verrouillée" / non bloquante) qui réutilise le pool interne pour produire plus de bits pseudo-aléatoires. Cela signifie que l'appel ne bloquera pas, mais la sortie peut contenir moins d'entropie que la lecture correspondante de / dev / random.

Donc, si votre intention n'est pas de générer CSPRNG (générateur de nombres pseudo-aléatoires cryptographiquement sécurisé), vous devez utiliser / dev / urandom.


Utilise-t-il /dev/randomvraiment des sources comme le bruit thermique? D'après ce que je comprends, il utilise des informations sur l'état du système (relativement) imprévisible, telles que l'activité des E / S et l'état du processus. Je ne pense pas que la plupart des systèmes Linux aient même du matériel qui peut générer du bruit thermique. Pouvez-vous citer de la documentation à ce sujet?
Keith Thompson

Oui, tu as raison. Les informations que j'avais mentionnées s'appliquent au Générateur de nombres aléatoires de matériel générique.
Sachin Divekar

Regardez le doc sur la façon dont il est implémenté sous Linux au lien . Là, il est mentionné que dans un environnement PC, le LRNG collecte l'entropie des événements provenant des interruptions du clavier, de la souris, du disque et du système. Dans d'autres environnements, le LRNG collecte l'entropie à partir des ressources disponibles. Par exemple, un routeur OpenWRT n'inclut pas de disque dur, de souris et de clavier et ne peut donc pas être utilisé comme source d'entropie. D'un autre côté, le routeur collecte l'entropie des événements du réseau.
Sachin Divekar

Vous pourriez peut-être mettre à jour votre réponse. Je ne pense pas qu'il soit exact de dire que cela /dev/randomgénère des "nombres vraiment aléatoires".
Keith Thompson

/ dev / random article sur wikipedia dit, Linux a été le premier système d'exploitation à implémenter un véritable générateur de nombres aléatoires de cette façon dans le premier paragraphe.
Sachin Divekar

2

Sans répondre à votre question - il y a déjà des réponses complètes ici - vous pouvez également consulter Darik's Boot et Nuke aka DBAN qui est un essuie-glace pour lecteur de CD live.


0

Utilisez simplement la shredcommande fournie avec coreutils. Il utilise des données aléatoires de manière efficace. dd est un outil de bas niveau et c'est probablement un niveau un peu trop bas pour cette tâche. shredsautera efficacement les parties non inscriptibles de l'appareil par exemple.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.