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

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...

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.

/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.

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.

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.

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.