/dev/randomと/dev/urandom

読み込みが行われると、 /dev/random デバイスはエントロピー・プールのノイズビットの数の評価値から、ランダム バイトのみを返す。 /dev/random はワンタイムパッド (one-time pad) や鍵の生成のような 非常に高い品質を持った無作為性が必要になる場合に適切であろう。 エントロピー・プールが空の時は、/dev/random からの読み出しは、 更なる環境ノイズが得られるまで、ブロックされる。

/dev/urandom デバイスから読み出しでは、 エントロピーがより高くなるのを待つためのブロックは行われない。 その結果、もしエントロピー・プールに十分なエントロピーが存在しない場合、 返り値はこのドライバで使われているアルゴリズムに基づく暗号攻撃に対して、 論理的には弱くなることになる。 この攻撃をどのように行うかという事については、現在研究論文などの 形で入手できる資料はない、しかし、そのような攻撃は論理的に存在可能である。 もし、この事が心配なら、(/dev/urandom ではなく) /dev/random を利用すればいい。

http://www.linux.or.jp/JM/html/LDP_man-pages/man4/random.4.html

PerlのCrypt::DSAのmake testがえらい時間かかるので、

$ strace -f prove -l t/02-sign.t

とかしてみたら、/dev/randomからのreadで待たされてる感が。

試しに、lib/Crypt/DSA/Util.pmの/dev/randomを/dev/urandomに書き換えてmake testしたら、t/03-keygen.tで寝そうになるぐらいまたされることはなくなりました。（それでもt/06-fip.tはちびっつまたされました）

/dev/urandomに書き換えるのは妥当かどうかは置いておいて、原因がわかったのでメモ。

ところで「環境ノイズ」って具体的にはなんなんでしょうかね？ ざわざわ