/dev/random はUnix系オペレーティングシステム (OS) における擬似デバイスの一種であり、乱数生成器として機能する。デバイスドライバその他の情報源から集めた環境ノイズを利用して、真の乱数性を得るのが目的である。全てのUnix系OSが /dev/random およびそれに類する機能を実装しているわけではない。また、それぞれの実装が、同じように振舞うわけでもない。このような擬似デバイスを実装した最初のOSはLinuxであった。このようなOSレベルの乱数用デバイスを実装した最初のOSカーネルが Linux であった。その設計が行われた当時、暗号について米国での輸出制限があったため、暗号ではなくハッシュ関数を使って実装されている。また、設計にあたっては任意のハッシュや暗号に脆弱性が発見される可能性があるという仮定を置いており、そのような脆弱性に耐性を持つよう設計されている。この実装では、エントロピープールにおけるノイズのビット数の予測を常に保持する。このエントロピープールから乱数を生成する。codice_1 から読み出すと、エントロピープール内のノイズビット数予測から乱数バイト列のみを返す。codice_1 は、ワンタイムパッドや鍵など、高度な無作為性を必要とする場合に使われる。エントロピープールが空の場合、codice_1 から読み出そうとするとブロックされ、環境ノイズの収集がなされるまで待たされる。これは、真の乱数生成器となることを意図したもので、可能な限り最も無作為なデータから実際のエントロピーを抽出しようとしたものである。また、長期間あるいは高度な保護のための暗号鍵の生成に使用することを意図していた。codice_1 と対をなす /dev/urandom ("unlocked" random source) も存在する。あり、こちらは内部プールを再利用することで擬似乱数的な乱数ビット列を生成する。すなわち、codice_5 へのアクセスはブロックされることがないが、codice_1 に比べると、真の乱数ではなく擬似乱数的に生成されている。ただし、暗号論的擬似乱数生成器として機能することを意図して、一般的な擬似乱数生成器ではなく、暗号論的擬似乱数生成器を使用している。codice_1 に書き込むことも可能である。これによりユーザーがプールに乱数データを混合させることが可能となる。たとえ書き込んだデータが乱数でなくとも害はない。というのも、エントロピー予測を増加させるioctlが必要であり、こちらは特権ユーザーでないと発行できない。現在のエントロピー量とエントロピープールの大きさは codice_8 で得られる。2006年3月に Gutterman らが発表した Linux の乱数生成器の暗号論的分析では、いくつかの弱点が指摘されている。その中でも最も重大な問題は、ルーターやディスクレスクライアントといった組み込みシステムや Live CD システムではブート状態が予測可能であり、環境ノイズから供給される利用可能なエントロピーが限られている点である。不揮発性メモリを持つシステムについては、シャットダウン時に乱数生成器の状態をセーブし、次回のブート時にそれを利用することを推奨している。例えばルーターでは主要なエントロピー源はネットワークトラフィックだが、この論文ではリブートをまたいで状態をセーブすることで、ルーターがサービスを開始した時点から「全てのネットワークトラフィックを潜在的攻撃者が盗み聞きする」か、ルーターの内部状態に直接アクセスする必要性を生じさせるとした。特に無線LANのルーターでは、そのネットワークトラフィックは遠隔から気づかれずに盗み聞きでき、データの暗号化のための鍵を乱数生成器で生成していることから、非常に重要である。Linuxカーネル3.17で、システムコールとしてcodice_9が追加された。これはcodice_1またはcodice_5からデータを読み出すことと同じ機能を提供するシステムコールである。デフォルトではcodice_5相当であり、オプションでcodice_1相当の動作も選択できる。codice_1やcodice_5はデバイスファイルであるため、使用する際にはcodice_16システムコールで開く（ファイル記述子を割り当てる）必要がある。そのため、ファイル記述子が限界まで使用済みの状態では、新たにファイルを開けないため、これら乱数の読み出しも不可能になる。これはリソース枯渇攻撃 ()に該当する。このため、システムコールとしての同機能が追加されることとなった。FreeBSDでは、以前は Linux のような実装だったが、256ビット版 を使って擬似乱数列を提供する実装になっている。Linux の codice_1 とは異なり、FreeBSD の codice_1 は決してブロックしない。つまり Linux の codice_5 に似ており、エントロピープールではなく暗号論的擬似乱数生成器として機能することを意図している（FreeBSD では /dev/urandom は random へのシンボリックリンクである）。攻撃者が内部状態を知らない場合、擬似乱数生成器であっても十分にセキュアであり、しかもエントロピープールよりもわかりやすい。エントロピープールによる実装は完璧に実装すれば完全にセキュアとなるが、エントロピー予測が過大だとうまく設定された擬似乱数生成器よりも弱くなる。攻撃者は場合によってはエントロピーの大部分を制御できる。例えば、ディスクレスサーバの場合、環境ノイズの多くはネットワークに由来するため、中間者攻撃に対して脆弱となる可能性がある。Yarrow ではプール枯渇を防ぎ、可能な限り素早く復旧することに重点を置いている。定期的な初期値の再設定が行われ、特にネットワークやディスクの使用量が少ないシステムでは、1秒未満の間隔で行う。FreeBSD ではハードウェア乱数生成器もサポートしており、今後 Yarrow を置換する可能性がある。codice_1 と codice_5 は Solaris、Mac OS X、NetBSD、OpenBSD、Tru64 UNIX 5.1B、AIX 5.2、HP-UX 11i v2 にもある。Microsoft Windows NT では、似たような機能として codice_22 が提供されているが、codice_23 というスペシャルファイルから読み込んでもUnix系と同様の動作はしない。暗号論的擬似乱数列を生成する方法として明記されているのは と である。EGD (Entropy Gathering Daemon) というソフトウェアは、/dev/random をサポートしていないUnix系システムでよく使われる。ユーザー空間で動作するデーモンであり、高品質の乱数データを提供する。OpenSSL、GNU Privacy Guard、Apache HTTP Server などの場合、/dev/random がないシステムでは EGD を利用できる。実装としては EGD や prngd があり、各種情報源から擬似乱数的エントロピーを収集し、偏りを除去して暗号的品質を高め、Unixドメインのソケット経由（/dev/egd-pool がよく使われる）やTCPソケット経由でアクセス可能にする。エントロピー収集は子プロセスを定期的にforkして行い、頻繁に変化し予測できないシステムの各種属性（CPU、I/O、ネットワーク、ログファイルの内容、一時ディレクトリの内容など）を調べる。EGD と乱数データを必要とする他のプログラムとのやりとりは単純なプロトコルで行う。クライアントはEGDソケットと接続し、先頭のオクテットが次のようなコマンドとなっている要求を送る。

出典:wikipedia