カーネル5.10.119にアップデートした後、/proc/sys/kernel/random/entropy_avail
256で停止してマウスを動かしても変わりません。以前は3,000を超えていました。
# cat /proc/sys/kernel/random/entropy_avail
256
また、/proc/sys/kernel/random/poolsize
256に落ちた。以前は4096でした。
これはバグですか?このカーネルの新しい乱数ジェネレータの利用可能なエントロピーは256個しかないと思いますか?
答え1
Marcusの完全な答えと競争する意図はありません。何が起こっているのかを説明し、あなたが見つけたものがバグではないことを証明するためです。
デフォルトのプールサイズはハードコーディングされていますが、drivers/char/random.c
5.10.119では実際に変更されています。
2011年10月5日現在:
#define INPUT_POOL_SHIFT 12
#define INPUT_POOL_WORDS (1 << (INPUT_POOL_SHIFT-5))
...
static int sysctl_poolsize = INPUT_POOL_WORDS * 32;
(2^(12-5))x32=4096
5.10.119以下、poolsizeは別々に計算されているようです。
POOL_BITS = BLAKE2S_HASH_SIZE * 8
...
static int sysctl_poolsize = POOL_BITS;
BLAKE2S_HASH_SIZE = 32、定義どおりinclude/crypto/blake2s.h
8x32=256あなたが見つけたのはバグではなく機能です!
ちなみに、これはデフォルト値にすぎないので、必要に応じない場合は自由に変更してください。
注:この変更は、5.17-rc1が119から5.10にバックポートされているが、44から最新のLTSにバックポートされたため、メインラインに関連しています。 5.15は(まだ?)気にしないようで、もちろん5.16もそうです。
@TooTeaがコメントで提案したように、これらの動きの理由は次のとおりです。初期コミット、一言で言えば:
- セキュリティ強化(プールの状態が漏洩したら、その内容を制御して完全にゼロにすることができます。)
- パフォーマンスの向上(高度なCPUで最大225%)
これは、4096 LFSR を BLAKE2 への直接呼び出しで置き換えることによって達成されます。
BLAKE2sは256ビットを出力し、適切な最小エントロピー蓄積量とアクティブ攻撃に対する十分な広い衝突抵抗マージンを提供します。
答え2
私たちはできます。
以前に同じ値を表示することもできます。 「エントロピー」は、擬似乱数ジェネレータの状態を修正するために使用できるランダム性のソース数のおおよその推測にすぎません。あるとしてもいいえ新しいエントロピーを使用すると、発電機はまだ信頼できる– 誰かが状態を把握しない限り(しなければならない不可能)。
したがって、秘密鍵の生成などの場合でも/dev/urandom(外部エントロピーソースで状態を変更できない場合でもPRNGを使用)を使用することと/dev/random(状態を変更することがない場合はブロックする)を使用することとの間にセキュリティ上の違いはありません。、〜しない限り攻撃者が何らかの魔法の方法でカーネルの内部PRNG状態を知っていた可能性があると仮定します(または非常に限られたデバイスではエントロピーソースがなく、状態が決定的であるため、Linuxを最初に起動するため)。数百ビットのエントロピーを使用すると、暗号化されたセキュリティPRNGがそう言うでしょう。誰もランダムジェネレータからデータを取得すると、内部状態を正常に推測できます。
実際に唯一の違いは、エントロピーがゼロの場合、すでに暗号化されており、安全なPRNGが再シードされないことです。 「ストア」のエントロピーが3000か256かはまったく重要ではありません。重要なことはできる再シードかどうか。 (前に述べたように、「暗号的に一般的な」作業を行わない限り、これは重要ではありません。攻撃者がパスワードを完全に知らない使い捨てパッドを実際にどのくらい頻繁に作成する必要がありますか?)コンピュータの状態は次のとおりです。一つ世代移転時点は壊れませんか? 「攻撃者は、ある時点でPRNGの暗号化状態を推論できるほど全能であるため」「NSAがRSAを壊そうとしました」のようなものではありません。 )
正直に言うと、
これはバグですか?このカーネルの新しい乱数ジェネレータの利用可能なエントロピーは256個しかないと思いますか?
カーネルがセキュリティ対策を弱めることはないと仮定する必要があります。そうでなければ、ランダム性ソースの理論的エントロピーは問題ではありませんが、カーネルは意図的にユーザーに知らせず、どのような方法で決定論的にします。 :)
カーネルが安全な回帰をしないと信じていない場合は、コンピュータが期待した数値を提供すると信じられないため失敗しました。そうですね…はい可能です。あるいは、このアップデートで表示されるエントロピーだけを変更するのではなく、ずっと前に独自のOSの構築を開始する必要がありました。
簡単に言うと:お使いのコンピュータが影響を受けない限りエントロピーが足りない一度、セキュリティ番号を作成しています。乱数を取得し始める前に、256エントロピーを1回だけ使用してから、システムの残りの寿命に0を使用してもかまいません! 256を持つことは、これまで以上に必要です。