dd の特異な動作の組み合わせを観察しています。 Linux の /dev/random の独特な振る舞いで .ちなみに、どちらも仕事に適したツールになることはめったにありません.
Linux の /dev/random 控えめにデータを返します。これは、疑似乱数ジェネレーターのエントロピーが非常に速い速度で消滅するという仮定に基づいています。新しいエントロピーの収集は遅いため、/dev/random 通常、一度に数バイトしか解放しません。
dd は、当初はテープ デバイス上で動作することを意図した、古くて厄介なプログラムです。 1kB の 1 ブロックを読み取るように指示すると、1 ブロックを読み取ろうとします。読み取りが 1024 バイト未満を返した場合は、それで十分です。つまり dd if=/dev/random bs=1K count=2 2 つの read(2) を作成します 呼び出します。 /dev/random から読んでいるので 、2 つの read 呼び出しは通常、使用可能なエントロピーに応じてさまざまな数のバイトを返します。 dd がデータのコピーに適している場合も参照してください。 (または、read() と write() が部分的な場合)
OS インストーラーまたはクローン作成者を設計している場合を除き、/dev/random を使用しないでください。 Linux では常に /dev/urandom . urandom man ページはやや誤解を招く可能性があります。 /dev/urandom 実際、長寿命の鍵を生成するためにさえ、暗号化に適しています。 /dev/urandom の唯一の制限 十分なエントロピーを提供する必要があるということです。 Linux ディストリビューションは通常、再起動の合間にエントロピーを保存するため、十分なエントロピーが得られないのは新規インストール時だけです。エントロピーは実際には減りません。詳細については、Is a rand from /dev/urandom secure for a login key? を参照してください。 /dev/random エントロピー プールを供給していますか?
dd のほとんどの用途 head などのツールでより適切に表現されます または tail . 2kB のランダム バイトが必要な場合は、実行します
head -c 2k </dev/urandom >rand
古い Linux カーネルでは、問題なく使用できます
dd if=/dev/urandom of=rand bs=1k count=2
なぜなら /dev/urandom 喜んで、要求されたバイト数を返しました。しかし、これはカーネル 3.16 以降では当てはまりません。現在は 32MB に制限されています。
一般的に、 dd を使用する必要がある場合 一定数のバイトを抽出し、その入力が通常のファイルまたはブロックデバイスからのものではない場合、バイトごとに読み取る必要があります:dd bs=1 count=2048 .
man 4 random から RHEL 5 ボックス:
読み取り時に、/dev/random デバイスは、エントロピー プール内の推定ノイズ ビット数内のランダム バイトのみを返します。
そのマシンでサイズが 213 バイトのファイルを取得します。男 4 ランダムに戻る:
<ブロック引用>読み取られると、/dev/urandom デバイスは要求されたバイト数を返します。
dd if=/dev/urandom of=rand bs=1K count=2 を呼び出すたびに 2048 バイトを取得します
この違いは、 dd if=/dev/random ... の呼び出しの間にマシンが生成するエントロピーの量によるものだと結論付けています
なぜ dd は データをドロップしますか？ ... ジル dd について、この魅力的な質問を投げかけました :
dd がデータのコピーに適しているのはいつですか? (または、read() と write() が部分的な場合)
以下はその質問の抜粋です:
* ... dd のせいにするのは難しくありません。たとえば、次のコードを試してください:**
yes | dd of=out bs=1024k count=10
出力ファイルのサイズを確認します (おそらく 10 MB をはるかに下回ります)。
私のコメント（質問の最後）は別として、このようなものは見るのが難しいです...ファイル $trnd であなたのバイトをキャッチします . bs=8 を半恣意的に選択しました
マウスを動かして、速度が上がるのを見てください。
コンピューターがアイドル状態 (AFK でネットワーク アクティビティなし) で、エントロピー プールを使い果たした後、2時間かかりました 12分 1192 だけを集める バイト、その時点でキャンセルしました。
その後、マウスを動かし続けたところ、1 とかなり短くなりました。 15 秒 同じバイト数を収集します。
これは、エントロピーの収集が CPU 速度ベースではなく、ランダム イベントであることを明確に示しています。 ベースであり、私の Ubuntu システムはマウスをその 重要 の 1 つとして使用します。 ランダム要因。
get=2048
trnd=/tmp/$USER.rnd; >"$trnd"
while (( $(wc -c <"$trnd") < $get )) ;do
dd if=/dev/random bs=8 count=1 2>/dev/null >>"$trnd"
echo -n "itt: $((i+=1)) ct: "; wc -c <"$trnd"
done
truncate -s $get "$trnd"
echo -e "\nfinal count: "; wc -c <"$trnd"