ddを使用すると、/ dev / randomが非常に遅くなるのはなぜですか？
大量のハードドライブを半安全に消去しようとしています。以下は20-50Mb/sで動作しています
dd if=/dev/zero of=/dev/sda
だが
dd if=/dev/random of=/dev/sda
動作しないようです。入力したときも
dd if=/dev/random of=stdout
Bs =とcount =に何を渡したかに関係なく、数バイトしか得られません
/ dev/randomを間違って使用していますか？このトラブルシューティングを進めるために、他にどのような情報を探す必要がありますか？スクリプトなどでこれを行う他の方法はありますか
makeMyLifeEasy | dd if=stdin of=/dev/sda
またはそのようなもの...
_/dev/random_と_/dev/urandom_はどちらも「エントロピープール」を使用します。プールが不足すると、_/dev/random_はシステムの動作（キーボード入力、マウスの動きなど）を監視する必要があるリフィルを待機しますが、_/dev/urandom_は引き続き疑似ランダムデータを提供します。理論的には_/dev/random_の方が品質は高くなりますが、_/dev/urandom_は目的に応じてほぼ間違いなく十分です。 （しかし、_/dev/urandom_でも他のいくつかの方法よりも低速である可能性があります。より高速ですが品質が低いジェネレーターは、おそらくハードドライブを消去するのに十分です。攻撃者が進行中のシーケンスを知ることで何らかの利点を得られるかどうかは明らかではありません。生成されるか、その乱数はこの目的のために0、1、2、3、4などのシーケンスよりも優れています。）
random(4)のmanページを引用：
_
/dev/random_と_/dev/urandom_のどちらを使用すべきかわからない場合は、おそらく後者を使用することをお勧めします。一般的なルールとして、_/dev/urandom_は、長期間有効なGPG/SSL/SSHキーを除くすべてに使用する必要があります。
[〜＃〜] update [〜＃〜]：私が書いてから、 `random（4）のmanページが更新されました。それは今言う：
_
/dev/random_インターフェースはレガシーインターフェースと見なされ、初期ブート時にランダム性を必要とするアプリケーションを除いて、すべてのユースケースで_/dev/urandom_が推奨され、十分です。これらのアプリケーションでは、エントロピープールが初期化されるまでブロックされるため、代わりにgetrandom(2)を使用する必要があります。
ThomasHühnによる " / dev/urandomに関する神話 "も参照してください。
しかし、ブロックされない場合でも、_/dev/urandom_は、大量のデータを生成したい場合、遅くなる可能性があります。試す前に、システムでいくつかの測定を行ってください。
EDIT：以下は、「真の」乱数と疑似乱数の違いです。興味のあるものが質問への実用的な答えである場合は、今すぐ読むのをやめることができます。
疑似乱数ジェネレーター（PRNG）ではなく、_/dev/random_が "真の"乱数ジェネレーターを実装していると（他の回答も含めて）主張しているようです。たとえば、 ウィキペディアの記事 はそのような主張をします。私はそれが正しいとは思わない。それについていくつかの議論があります here これはハードウェア乱数発生器を指しますが、_/dev/random_が通常そのようなデバイスを使用しているという証拠、または一般的なコンピューターがそのようなデバイスを持っているという証拠はありません。これらはC Rand()関数のようなPRNGとは異なり、実際には予測できないソースからエントロピーを取得するため、確定的ではありません。
「ランダムな」数値ジェネレーターには3つのクラスがあると思います。
Cの
Rand()関数のような決定論的PRNG。アルゴリズムを使用して、真にランダムなシーケンスの統計的特性（多かれ少なかれ）を持つ反復可能なシーケンスを生成します。これらはゲームに十分対応でき（シードの良い方法が与えられた場合）、再現性を必要とするアプリケーションに必要ですが、暗号化には適していません。_
/dev/random_や_/dev/urandom_などのジェネレーターは、I/Oアクティビティなどの実際には予測できないソースからエントロピーを取得します（これが、キーボードを叩いたり、マウスを動かしたりすると、_/dev/random_がより多くのデータを生成する原因となるためです） 。これらがa PRNG（私はa PRNGは決定論的であると言う定義を見てきました）を満たすかどうかは、私にはわかりません）それらtrue乱数ジェネレータ。ハードウェア乱数発生器 初期状態を完全に知っていても物理的に予測不可能であり、さらに数学的な手法を使用して正しい統計特性を保証します。
/dev/randomは、真のランダムバイトの真のエントロピーのソースです。そのため、ランダム性のソースが必要です。ランダム性を読み取ることで、ランダム性を「使い切る」ことができます。それはあなたにそれが持っているすべてのランダムさを与え、それがより多くなるまでブロックします。おそらくそこに座って待っているだけで、マシンは新しいランダム性をほとんど取得せず、そのまま待機します。
/dev/random真にランダムな暗号、高品質のランダム性。そのため、ディスクドライブの上書きには過剰です。 /dev/zeroから数回書いても問題ありません。または、/dev/urandomから書き込むこともできます。これにより、真のランダム性が不足してもブロックされず、疑似乱数が生成されます。
Linuxでは/ dev/randomは 特別 ファイルで、高品質の疑似乱数を提供します。 この実装は、キーボード、マウス、ディスク、およびシステムの割り込みから発生するイベントからエントロピーを収集します。（- this ドキュメントを参照）そのようなイベントはなく、エントロピープールは空です。追加の環境ノイズが収集されるまで、/ dev/randomからの読み取りはブロックされます。これはあなたの問題を説明しています。エントロピープールを満たすには、キーボードのキーを押します。
もう1つの注意点として、真の乱数ジェネレータは、物理プロセスから乱数を生成する ハードウェア乱数ジェネレータ を使用します。これらのプロセスには、次のような低レベルの統計的にランダムな「ノイズ」信号を生成する微視的な現象が含まれます。熱雑音または光電効果または他の物理現象。これらのプロセスは、理論的には完全に予測不可能であり、予測不可能性に関する理論の主張は実験的テストの対象となります。
ハードウェア乱数発生器は、通常、物理現象の一部の側面を電気信号に変換するトランスデューサー、ランダムな変動の振幅を巨視的なレベルに増加させるアンプやその他の電子回路、およびある種のアナログデジタルコンバーターで構成されています出力をデジタル数値（多くの場合、単純な2進数の0または1）に変換します。ランダムに変化する信号を繰り返しサンプリングすることにより、一連の乱数が得られます。
Hardware Random Number Generatorは、デバイスドライバーやその他のソースからの環境ノイズをエントロピープールに収集します。このエントロピープールから乱数が作成されます。/dev/randomデバイスは、読み取られると、エントロピープール内のノイズの推定ビット数内のランダムバイトのみを返します。これはあなたの問題を説明しています。
ハードウェアRNGのいくつかの実装は、 kernel doc および デバイスの情報 で説明されています。
/ dev/randomに対応するものは/ dev/urandom（「ロック解除」/非ブロッキングランダムソース）で、内部プールを再利用して、より多くの疑似ランダムビットを生成します。つまり、呼び出しはブロックされませんが、出力には/ dev/randomからの対応する読み取りよりも少ないエントロピーが含まれる可能性があります。
したがって、意図がCSPRNG（暗号で保護された疑似乱数ジェネレータ）を生成しない場合は、/ dev/urandomを使用する必要があります。
あなたの質問に答えなくても-ここにはすでに完全な答えがあります-Darik's BootとNuke akaもチェックできます [〜＃〜] dban [〜＃〜] ライブCDドライブワイパーです。
Coreutilsに付属するshredコマンドを使用するだけです。効率的な方法でランダムデータを使用します。 ddは低レベルのツールであり、おそらくこのタスクには少なすぎるレベルです。 shredは、デバイスの書き込み不可能な部分を効率的にスキップします。