短い答えはイエスです。長い答えもイエスです。 /dev/urandom 既存の技術を考えると、真のランダム性と見分けがつかないデータが得られます。 /dev/urandom よりも「良い」ランダム性を得る 数少ない「情報理論的」暗号化アルゴリズムの 1 つを使用していない限り、提供は無意味です。
urandom の man ページ /dev/urandom を示唆している場合、やや誤解を招く可能性があり、間違いなく完全に間違っています。 「エントロピーを使い果たす」可能性があり、/dev/random 優先する必要があります。 /dev/urandom の唯一の瞬間 かも 低エントロピーによるセキュリティの問題が、自動化された新しい 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 の「secure」フラグと「HttpOnly」フラグを設定します)。
はい、素晴らしい方法です。
@トーマスの説明はそれを釘付けにします。そして彼が /dev/urandom を批判するのは完全に正しい マンページ。スポット。
ただし、「既に存在するかどうかの確認」はスキップしてください。そのチェックは無意味です。それは起こらないだろう。 (その可能性は、同じ日に複数回雷に打たれる可能性よりも低くなります。)