大規模なソフトウェアプロジェクトで作業するときは、テストケースの一部としてファズテストを使用して、入力が特定のサイズまたは形状に達したときにのみ発生する可能性のあるバグを排除するのに役立てることがよくあります。私はこれを最も一般的に行っているのは、たまたま使用しているプログラミング言語にバンドルされている標準の乱数機能を使用することです。
最近、ファジングテストを行うときに暗号論的に安全でない疑似乱数ジェネレータを使用するのが良いかどうか、一般的なファジングテストの長所と短所を無視して疑問に思い始めました。弱い乱数ジェネレーターは、それらのパターンがすぐに明らかにならない場合でも、真の乱数シーケンスと区別するパターンを示すことがよくあります。弱いPRNGを使用したファズテストでは、特定の状況でのみ発生する特定の潜在的なバグを常にトリガーできない可能性があります。これは、疑似乱数が相互に関連している可能性があるためです。
ファジングテストに弱いPRNGを使用することは本質的に賢明ではありませんか？そうすることが理論的に不健全である場合、それは実際にはまだ合理的ですか？
あなたは「弱さ」の2つの非常に異なるグレードを混同しています：
それほど重要ではないと思いますが、証明することはできません。
ファズテストでは、一部の入力のみが試行されます。ほとんどの場合、可能性のごく一部です。使用するRNGがどれほど優れていても、考えられるすべての入力のどの割合がコードを壊すかによって、コードを壊す入力の1つが見つかる場合と見つからない場合があります。PRNGのパターンが非常に単純でない限り、探している「悪い」入力のパターンに何らかの形で対応する可能性は低いと思われるため、真のランダム以上でもそれ以下でもヒットしません。
実際、RNGを選択して不正な入力を見つける可能性を最大化する方法を知っている場合は、おそらくその知識を使用して、バグをより直接的に見つけるのに役立てることができます...
本当に悪いPRNGを使うべきではないと思います。randたとえば、LSB交互などの非常に単純なパターンを示すことが許可されています。また、コードでPRNGを内部で使用する場合は、入力データが内部で生成された数値ストリームと一致するケースのみを誤ってテストしないように、テストで同じPRNGを同じように使用することは避けてください。もちろん、彼らが異なるシードを使用することを望んでいるので、小さなリスクですが、それでも。
通常、特定の言語では、暗号または少なくとも安全なハッシュライブラリを見つけるのはそれほど難しくありません。SHA-1はどこにでもあり、ストリームを生成するために簡単に使用できます。または、RC4に失敗すると、自分で実装するのは簡単です。Blum Blum Shubほど安全ではないにしても、どちらもかなり良いPRNGを提供します。主な関心事は速度だと思っていました。たとえば、メルセンヌツイスターがファズテストケースを10倍の速さで生成でき、テスト対象のコードが適度に速い場合、特定の入力で不正な入力を見つける可能性が高くなります。 624の出力が与えられたという事実に関係なく、RNGの完全な状態を推測することができます...
予測不可能なソース（暗号的に安全なジェネレーターとまったく同じ）は必要ありません。必要なのは、優れた統計的特性を備えたソースだけです。
したがって、汎用ジェネレーターを使用するだけで十分です。高速で、通常は再現可能です（つまり、問題も再現可能です）。