てきとうなメモ

本の感想とか技術メモとか

shredはcoreutils v7.1から/dev/urandomを使わなくなった

shred は -n でパス数を指定できて、-n 3くらいにすると3パスともランダムなデータの書き込みになります。 coreutils-6.9では、デフォルトでこの乱数は/dev/urandomからとってきているのですが、非常に遅いです。

昔これ読んでshred使うときは気をつけようと思っていたのだが、coreutils 7.1から内部の擬似乱数生成器を使うようになったとのこと

Since coreutils v7.1 shred uses the internal PRNG by default:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=af5723c7

Suggestion from Steven Schveighoffer at:
http://savannah.gnu.org/patch/?6797
to greatly speed up the random passes done by shred.
* gl/lib/randread.c: Default to using the internal
pseudorandom generator, rather than reading /dev/urandom

議論の部分を読むと、

A:「ハードディスクのデータ全削除しようとしてるんだけども、/dev/urandomがある時とない時で速度がぜんぜん違うよ。/dev/urandomがあっても内部のPRNG使えるようにしてよ」
B:「"--random-source=ランダムなビット列のファイル"とすれば、できるよ」
A:「そんなでかいランダムなファイル作れないよ」
C:「プロセス置換とかFIFOとか使えばいいのでは」
A:「なるほど。でも、内部のPRNGが実装済みなんだから使えるようにすべきでは」
D:「そもそも、そんだけでっかいと/dev/urandom使ってもエントロピー消費しつくすんじゃない?」
E:「v7.1から内部のPRNG使えるようにしたよ」

てな感じ。

/dev/urandomがどれぐらいの強度なのかがよくわからんので、どこまで安全性が下がるのかよくわからんけど、実装済みなんだから使えるようにすべきではというのはまあそうだよねえ。