次のコードを読みました。
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
どうやら、このコードは、128ビットのバイナリ疑似ランダム値から16進文字列キーを生成するためのトリックとして使用されました。
「安全でないハッシュ関数」を介して暗号的に安全なランダム値を渡すので、誰かがこれは本質的に安全でないと主張しました。
私の側では、ハッシュ関数の入力と出力のサイズが同じであるため、md5の衝突の欠陥はここでは関係ありません。したがって、ハッシュ関数の出力はその入力と同じくらいランダムです。
それについてどう思いますか? NビットランダムキーをハッシュしてNビットハッシュを生成すると、キーのランダム性が変わりますか?
ハッシュは決定論的なプロセスであり、ランダム性を高めることはありません。しかし、もちろんランダム性を減らすことができます。たとえば、SHA-1のように160ビットしか出力しないハッシュアルゴリズムで200ビットのランダム値をハッシュすると、結果の値に200ビットのランダム性が含まれることはありません。
ただし、入力ビット数がハッシュの出力サイズよりも大幅に少ない限り、暗号化ハッシュが使用される場合、ランダム性は低下しません。例のように入力サイズが入力サイズとまったく同じである場合、暗号化ハッシュを使用しても、結果として得られるランダム性はそれほど低下しない可能性があります。そして、衝突抵抗はこれには関係ないというのはあなたの言うとおりです。
_dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
_
これはある程度のエントロピーを失うことが保証されていますが、それほどではありません。 MD5への攻撃の難しさは、損失の量を直接示唆するものではなく、それがゼロではないことを示しているだけです。
単純な構造に頼ると、エントロピー損失は、固定小数点確率 63.21%。 から計算できることがわかります。これは、失われたエントロピーが1ビット未満であることを意味します。本当に必要だと言われているのを忘れていますが、122ビットの真のエントロピーで十分です。
一方、ここで何を達成しようとしていますか? _dd if=/dev/urandom bs=16 count=1
_はそれだけで十分です。弱点に対して kekkak-f を防御するためにmd5を使用しようとしても意味がありません。
ここで何かする必要があると本当に感じた場合は、128ビットアプリケーションの秘密鍵を作成し、インストール時に_/dev/random
_(urandom
ではない)から直接生成し、_/dev/urandom
_。しかし、これを行うために指を離す理由が1つだけではありません。