これは正式にテストされていないハードウェア実装であり、独自のものです。潜在的な懸念は、Intel が NSA の要求で実装にバックドアを仕掛けた可能性があることです。
rdrand 出力を Linux カーネル PRNG に混合する現在の方法は、プールに xor されることです。これは、数学的には、rdrand 実装からの弱い出力がプール全体を弱める可能性がないことを意味します-それはそれを強化しますまたはセキュリティに何もしません。
ただし、実際のリスクは、特別なシナリオで rdrand の使用を検出する方法で xor 命令がバックドアされ、xor が呼び出されたときに異なる出力を生成することです。のみ 意図的に弱められた rdrand 出力がプールに配置されます。
実現可能？はい。もっともらしい？最近の啓示を考えると、多分。バックドアである場合、Linus はそれに加担していますか?あなたの推測は私のものと同じです。
また、CPU のトランジスタ レベルでハードウェア バックドアを隠すことに関する優れた論文もあります。
編集、2019 年 2 月。 ユーザー Luc は、この回答が最初に書かれてから状況が変わったことを以下にコメントしました:
<ブロック引用>Linux 4.19 以降、ブート時に random.trust_cpu=0 フラグを渡さない限り (またはコンパイル時に設定しない限り)、カーネルは RDRAND を信頼して CSPRNG を完全にシードします。これが最初の起動でない場合は問題にはなりませんが、新しくインストールされたシステムまたは新しく作成された VM には、予測可能な起動シード ファイルがある (またはシード ファイルがまったくない) 可能性があるため、これらのシステムでは、これは適切なエントロピーを収集するために関連しています。
RdRand 命令は、これらのプロセッサに現れたハードウェアのバグにより、Ivy Bridge で壊れています。エラー以外の理由があるとは考えにくい。決定論的疑似乱数アルゴリズムを使用してシードされた暗号化アルゴリズムは、おそらく本物の乱数でシードされたものよりも数億倍簡単に破ることができます。私は実際にその命令の恩恵を受けるエンジニアリングアプリケーションを持っていますが、それは不正な命令例外を引き起こします私の新しい Ivy Bridge ラップトップ。お金を取り戻すことはできますか?ハードウェアのバグに関する最初の情報については、RdRand のウィキペディアのエントリを参照してください。