2011年8月13日23:12 NARUSE, Yui <naruse / airemix.jp>:

>> PRNGである以上、seedが予測されたら、全乱数列が予測されてしまうので、
>> 安全側に倒すほうがエントロピー枯渇よりも重要なんじゃないかという気がするんですけどねえ・・
>>
>> OSのレベルでも、ASLRの実現のためにprocess
>> spawnするたびに/dev/urandom読んでるので、許容範囲内ではないかなあ。恣意的な運用を考えたらダメなケースは発生しうるかもしれないけど
>
> /dev/random ではなく urandom なのでいいんじゃないでしょうか、
> もちろんエントロピーは消費するわけですが。

forking server だと request ごとに消費しちゃうというのが嫌な感じなのですが、
OS 自体の消費に対して線形ならいいかなぁと思いつつも、

> 加えて、現在攻撃側に経って考えると usec/nsec * pid あたりが予測不可能性を担保しているところ、
> これって 100万~1億 * 6万なわけで、42bit くらいしか空間ありませんよね。
> ちょっと seed が弱いと思うんです。

これは違います。
RAND_seed() はその時点の種にデータを混ぜるものなので、
最初に openssl が /dev/urandom から読んだ種が消えるわけではありません。

RAND_add(3SSL):
  RAND_add() mixes the num bytes at buf into the PRNG state.
-- 
[田中 哲][たなか あきら][Tanaka Akira]