乱数の確実に真にランダムなソースがあると仮定しましょうが、それは非常に遅いです。数時間ごとに数百の数字しか得られません。
それ以上のものが必要なので、java.util.Random (または scala.util.Random) のシードとして取得できるいくつかの貴重な TRN を使用することを考えていました。また、次の乱数を生成するために常に新しいものを選択します。
したがって、私の質問は次のとおりだと思います。シードが本当にランダムであるため、Java の Random インスタンスから生成した数値を本当にランダムと見なすことができますか? 真のランダム性のために満たされていない条件がまだありますか? レベルを追加し続けると、どの時点でランダム性が失われますか? それとも（私がそれを思いついたときに思ったように）種の流れがある限り本当にランダムですか？
シードの流れを傍受した人は誰もいないと思いますが、これらの番号をセキュリティ目的で使用する予定はありません。
のような疑似乱数発生器の場合java.util.Random、数列から少数の数だけが与えられると、数列で次に生成される数が予測可能になるため、「真のランダム性」が非常に速く失われます。が提供するジェネレーターの 1 つを使用することをお勧めしますjava.security.SecureRandom。これらはすべて、非常に長いシーケンス長を持つ強力なランダム ジェネレーターであり、予測するのはかなり難しいはずです。
私たちの Java Random は、均一に分散された乱数を提供します。これは真のランダム性ではなく、同じ数の 5 倍になる可能性があります。
さらに、すべての特定のシードに対して、同じシーケンスが (意図的に) 生成されます。一般に 2^64 シードは無関係です。(ハッカーはすべてのシーケンスの最初の 10 個の数字を保存できるので、すぐに追いつくことができることに注意してください。)
したがって、広い間隔で真の乱数をシードとして使用すると、その間隔で均一な分布が得られます。実際には、真のランダマイザーを使用しない場合と大差ありません。
ランダムなシーケンスを組み合わせると、ランダム性が低下する可能性があります。おそらく、真の乱数をバイトに変換し、すべての新しい乱数を別のバイトと xor 演算すると、より大きな差異が生じる可能性があります。
私の言葉だけを鵜呑みにしないでください - 上記の数学的正確性を保証することはできません。数学/アルゴリズムのフォーラムでより多くの情報が得られるかもしれません。
入れたビットよりも多くのビットを取り出すと、それらはもはや完全にランダムではなくなります。乱数ジェネレーターが不良の場合、ブレーク ポイントがさらに早く発生する可能性があります。これは、シーケンスのエントロピーを考慮することで確認できます。シード値によってシーケンスが完全に決定されるため、多くてもシード値と同じ数のシーケンスが存在します。それらがすべて異なる場合、エントロピーはシードのエントロピーと同じです (シードが本当にランダムであると仮定すると、これは本質的にシード ビットの数です)。
ただし、異なるシードが同じ疑似乱数シーケンスにつながる場合、シーケンスのエントロピーはシードのエントロピーよりも低くなります。n ビット後のシーケンスを切り捨てると、エントロピーはさらに低くなる可能性があります。
しかし、セキュリティ目的で使用しないのであれば、気にする必要はありません。疑似乱数がアプリケーションにとって十分ではないことは確かですか?