ddを使用するときに/ dev / randomが非常に遅いのはなぜですか?


29

大量のハードドライブを半安全に消去しようとしています。以下は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

またはそのようなもの...


1
注:CIAがデータを追跡する疑いがない限り、ゼロ(/ dev / zero)で1回上書きするだけで十分でしょう。たとえば、superuser.com / questions / 215852 /…を参照してください。
sleske

読み取り/dev/randomが数バイトしか返さない理由については、superuser.com
a / 712515/139307

回答:


42

両方/dev/random/dev/urandom「エントロピープール」を使用します。プールがなくなると、プールが/dev/random補充されるまで待機します。これには、システムの動作(キーボード入力、マウスの動きなど)を監視する必要があり/dev/urandomますが、擬似ランダムデータは引き続き提供されます。 /dev/random理論的には高品質です/dev/urandomが、ほぼ確実に目的には十分です。(しかし/dev/urandom、他の方法よりも遅くなる可能性があります。より高速であるが品質が低いジェネレーターは、おそらくハードドライブを消去するのに十分です。乱数はこの目的に適しているは、 0、1、2、3、4、...などのシーケンスよりもです)

random(4)マニュアルページを引用する:

使用すべきかどうかわからない場合 /dev/randomまたは /dev/urandom、おそらく後者を使用する必要があります。一般的なルールとして、/dev/urandom長期間有効なGPG / SSL / SSHキーを除くすべてに使用する必要があります。

更新: `random(4)manページは、私がそれを書いてから更新されました。それは今言う:

/dev/randomインターフェースは、レガシーインターフェースと考えられ、 /dev/urandom早期のブート時にランダム性を必要とするアプリケーションを除いて、好ましく、すべてのユースケースで十分です。これらのアプリケーションの場合、getrandom(2)は、エントロピープールが初期化されるまでブロックされるため、代わりに使用する必要があります。

/ dev / urandomに関する神話ThomasHühnの「。

しかし /dev/urandom、ブロックしませんが、大量のデータを生成する場合は遅すぎる可能性があります。試す前に、システムでいくつかの測定を行います。

編集:以下は、「真の」乱数と擬似乱数の余談です。あなたが興味を持っているのが質問に対する実際的な答えだけであるならば、あなたは今読むのをやめることができます。

/dev/random疑似乱数ジェネレーター(PRNG)とは対照的に、「真の」乱数ジェネレーターを実装するという主張(ここの他の回答を含む)があるようです。たとえば、ウィキペディアの記事はそのような主張をしています。私はそれが正しいとは思わない。ここでは、ハードウェア乱数ジェネレーターに関するいくつかの議論がありますが、/dev/random通常、そのようなデバイスを使用している、または典型的なコンピューターがそのようなデバイスさえ持っているという証拠は見当たりません。CのようなPRNGとは異なりますrand()は、実際には予測不可能なソースからエントロピーを収集するため、関数の決定論的ではありません。

「乱数」ジェネレータには3つのクラスがあります。

  1. Cのrand()関数のような決定論的PRNG。アルゴリズムを使用して、真にランダムなシーケンスの(ほぼ)統計的特性を持つ反復可能なシーケンスを生成します。これらはゲームに十分なものであり(シードの良い方法が与えられます)、再現性を必要とするアプリケーションには必要ですが、暗号化には適していません。

  2. のようなジェネレーターは/dev/random/dev/urandomI / Oアクティビティのような実際には予測不可能なソースからエントロピーを収集します(これが、キーボードをたたいたりマウスを動かしたりすると、/dev/randomより多くのデータが生成される原因です)。これらはPRNGの定義を満たしているか(私にはわかりません)(PRNGは決定論的であるという定義を見てきました)、どちらも真の乱数ジェネレーターではありません。

  3. 初期状態を完全に理解していても物理的に予測不可能であり、数学的な手法を使用して適切な統計特性を確保するハードウェア乱数ジェネレーター


2
(暗号化されたファイルシステムを作成する前にパーティション全体のように)大量のディスクスペースを埋めなければならない場合、/ dev / urandomでも少し遅くなります。これは、優れた答えと詳細な説明への小さな追加としてとられるべきです。
vtest

1つのランダムビットから1ビット以上のエントロピーを計算/導出/作成/ ...できないため、入力として受け取ったよりも多くの「ランダム」ビットを生成/出力するものは、せいぜい擬似ランダムです。したがって、/dev/urandom明らかに擬似ランダムです。/dev/random入力のエントロピーを控えめに見積もろうとする点で異なり、実際に考えられるよりも多くのエントロピーを出力しません(考える)。これは、専用のTRNGデバイスの存在とは無関係です。真のエントロピーは、キーボードやネットワークIO対時間など、あらゆる種類の独立したイベントからも取得できるためです。
JimmyB

13

/dev/random真のエントロピー、真にランダムなバイトのソースです。そのため、ランダム性のソースが必要です。ランダム性を読み取ることで、ランダム性を「使い切る」ことができます。それはあなたにそれが持っているすべてのランダム性を与え、それがそれ以上になるまでブロックします。おそらくそこに座って待っているだけで、マシンは新しいランダム性をほとんど獲得せず、ただ待っています。

/dev/random真にランダムな暗号化のために、高品質のランダム性。そのため、ディスクドライブの上書きはやり過ぎです。/dev/zero数回の書き込みは問題ありません。または/dev/urandom、から書き込むことができます。これは、真のランダム性がなくなったときにブロックせず、擬似乱数を生成します。


10
いいえ、/dev/random「真にランダムなバイト」を生成しません。生成するよりも高品質の擬似ランダムバイトを生成/dev/urandomします。
キーストンプソン

7

Linuxでは、/ dev / randomは高品質の擬似乱数を提供する特別なファイルです。 この実装は、キーボード、マウス、ディスク、およびシステムの割り込みから発生するイベントからエントロピーを収集します。これを参照ドキュメントを)そのようなイベントがない場合、エントロピープールは空で、追加の環境ノイズが収集されるまで/ dev / randomからの読み取りはブロックされます。これはあなたの問題を説明しています。エントロピープールを満たすには、キーボードのキーを押します。

一方、真の乱数ジェネレーターは、物理プロセスから乱数を生成するハードウェア乱数ジェネレーターを使用します。これらのプロセスには、熱ノイズや光電効果などの低レベルの統計的にランダムな「ノイズ」信号を生成する微視的現象が含まれます。その他の物理現象。これらのプロセスは、理論的には完全に予測不可能であり、予測不可能性の理論の主張は実験的テストの対象となります。

ハードウェア乱数ジェネレーターは、通常、物理現象の一部を電気信号に変換するトランスデューサー、増幅器およびその他の電子回路で構成され、ランダムな変動の振幅を巨視的なレベルまで増加させます。出力をデジタル数(通常は単純な2進数0または1)に変換します。ランダムに変化する信号を繰り返しサンプリングすることにより、一連の乱数が取得されます。

ハードウェア乱数ジェネレーターは、デバイスドライバーやその他のソースからの環境ノイズをエントロピープールに収集します。このエントロピープールから乱数が作成されます。読み取られると、/ dev / randomデバイスは、エントロピープール内のノイズの推定ビット数内のランダムバイトのみを返します。これはあなたの問題を説明しています。

ハードウェアRNGのいくつかの実装については、カーネルのドキュメントデバイスの情報で説明されています

/ dev / randomに対応するのは/ dev / urandom(「ロック解除」/非ブロッキングランダムソース)で、内部プールを再利用してより多くの擬似ランダムビットを生成します。これは、呼び出しがブロックされないことを意味しますが、出力には、/ dev / randomからの対応する読み取りよりも少ないエントロピーが含まれる場合があります。

したがって、目的がCSPRNG(暗号学的に安全な疑似乱数ジェネレーター)を生成しない場合は、/ dev / urandomを使用する必要があります。


/dev/random本当に熱雑音などのソースを使うのか?私の理解では、I / Oアクティビティやプロセスステータスなどの(比較的)予測できないシステムステータスからの情報を使用するということです。ほとんどのLinuxシステムには、熱ノイズを吸収できるハードウェアさえないと思います。これに関するいくつかのドキュメントを引用できますか?
キーストンプソン

はい、あなたは正しいです。私が言及した情報は、一般的なハードウェア乱数ジェネレーターに適用されます。
サチンディヴェカー

linuxでの実装方法については、リンクのドキュメントをご覧ください。PC環境では、LRNGはキーボード、マウス、ディスク、およびシステムの割り込みから発生するイベントからエントロピーを収集することが言及されています。他の環境では、LRNGは利用可能なリソースからエントロピーを収集します。たとえば、OpenWRTルーターにはハードディスク、マウス、キーボードが含まれていないため、これらをエントロピーソースとして使用することはできません。一方、ルーターはネットワークイベントからエントロピーを収集します。
サチンディヴェカー

おそらく、答えを更新できます。/dev/random「真の乱数」を生成すると言うのは正確ではないと思います。
キーストンプソン

ウィキペディアの/ dev / random記事によると、Linuxは最初の段落でこのように真の乱数ジェネレーターを実装した最初のオペレーティングシステムです。
サチンディベカー

2

あなたの質問に答えずに-ここにはすでに完全な答えがあります-また、DarikのBootと、ライブCDドライブワイパーであるNuke aka DBANも確認できます。


0

shredcoreutilsに付属のコマンドを使用してください。ランダムなデータを効率的な方法で使用します。ddは低レベルのツールであり、このタスクにはおそらく低すぎるレベルです。 shredたとえば、デバイスの書き込み不可部分を効率的にスキップします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.