/ dev / urandomのRandはログインキーに対して安全ですか？
ユーザーのCookieを作成したいとしましょう。 / dev/urandom を使用して1024bit文字列を生成し、それがすでに存在するかどうかを確認します（取得するまでループします）ユニークなもの）で十分ですか？
他の何かに基づいてキーを生成する必要がありますか？これはどういうわけか悪用される傾向がありますか？
短い答えはイエスです。長い答えもイエスです。 /dev/urandomは、既存のテクノロジーでは、真のランダム性と区別がつかないデータを生成します。いくつかの「情報理論」暗号アルゴリズムの1つを使用しているのでない限り、/dev/urandomが提供するよりも「より良い」ランダム性を取得しても意味がありません（ご存知でしょう）。
urandomのマニュアルページは、/dev/urandomが「エントロピーを使い果たす」可能性があり、/dev/randomを優先する必要があることを示唆している場合、誤解を招く可能性があり、間違いなく間違いです。エントロピーが低いために/dev/urandommightがセキュリティの問題を示唆する唯一の瞬間は、新しく自動化されたOSインストールの最初の瞬間です。マシンが何らかのネットワークアクティビティを開始し始めるところまで起動した場合、すべての実際的な使用に十分な高品質のランダム性を提供するのに十分な物理的ランダム性を収集しました（ここでLinuxについて話している; FreeBSDでは、その瞬間のわずかな瞬間弱点はまったく発生しません）。一方、/dev/randomは、不適切なタイミングでブロックされる傾向があり、非常に現実的で厄介なユーザビリティの問題につながります。または、もっと簡潔に言うと、/dev/urandomを使用して幸せになります。 /dev/randomを使用して申し訳ありません。
（編集：このWebページ は、/dev/randomと/dev/urandomの違いを非常に明確に説明しています。）
「Cookie」を生成するために、このようなCookieは、2人のユーザーが同じCookieを共有しないようにする必要があり、既存のCookieの値を「推測」することは誰にとっても計算上不可能です。ランダムバイトのシーケンスは、適切な品質のランダム性（/dev/urandomで問題ない）を使用し、十分な長さである限り、これで十分です。経験則として、2未満の場合んユーザー（n = 33地球全体の人口があなたのシステムを使用できる場合）、次にn + 128ビットは十分に広いです。既存の値との衝突をチェックする必要さえありません。一生の間にそれを見ることはありません。 161ビットは21バイトに収まります。
より短いCookieが必要で、データベース内の衝突を検索しないようにしたい場合に実行可能ないくつかのトリックがあります。しかし、これはCookieにはほとんど必要ないはずです（私はWebベースのコンテキストを想定しています）。また、Cookieの機密を保持することを忘れないでください（つまり、HTTPSを使用し、Cookieに「セキュア」フラグと「HttpOnly」フラグを設定します）。
はい、それは素晴らしい方法です。
@トーマスの説明はそれを釘付けにします。そして、彼は/dev/urandomのmanページを批判するのは完全に正しいことです。スポット。
ただし、「すでに存在するかどうかの確認」はスキップしてください。そのチェックは無意味です。それは起こりません。 （そのようなことが起こる可能性は、同じ日に雷が何度も打たれる確率よりも低いです。）
LinuxまたはNetBSDを使用している場合は、エッジケースに注意してください。
Linuxでは、CSPRNGを適切にシードするために、ブート後に十分なエントロピーが得られていることを確認するか、または getrandom() システムコールを使用して/dev/urandomから読み取ります。そして、十分な起動後の初期シードエントロピーが利用できないというまれなイベントでのみブロックします。
NetBSDでは、/dev/randomから読み取る前に/dev/urandomから少なくとも1回読み取って、正しくシードされていることを確認する必要があります。
FreeBSDとMacOSでは、/dev/randomと/dev/urandomの間に違いはありません。
短い答えは、まだ/dev/urandomを使用することです。
詳細は / dev/random vs/dev/urandomを使用する場合 を参照してください。