Quote from: satoshi on July 25, 2010, 08:01:40 PM
Quote from: knightmb on July 25, 2010, 07:44:02 PM
公開鍵123456がハッシュABCDを生成すると分かったとして
かつ 公開鍵654321もハッシュABCDを生成するとわかったとしても、 秘密鍵は依然としてわからない。
しかしあなたの言うことでは、公開鍵654321さえあれば、公開鍵123456のふりをしてコインを使えるということだ。 それでも公開鍵654321で署名する必要がある。秘密鍵を知っている公開鍵を使って衝突を見つける必要がある。
ビットコインアドレスのトランザクションを要求する際、ハッシュに一致する公開鍵を提示し、その鍵で署名する必要がある。
Redのポイントは、安全でない公開鍵を素早く大量に生成することは簡単で、衝突を見つけた後にそれを破って秘密鍵を見つけることができるということだ。
彼は、公開鍵が安全なものである必要がある場合、つまり素数を見つけるために相当な作業が必要なものである場合、ハッシュ関数単独よりも強度が増すと指摘している。ブルートフォースを試みる人は、各試行ごとに鍵を生成するのに時間をかける必要がある。
そうだ、秘密鍵が絡む必要があると思った。ただ、別のランダム性を追加するわけで、別の公開鍵と衝突するハッシュを見つけるだけでなく、同時にその秘密鍵が破れるほど弱くなければならない。不可能とは言わないが、2つの変数が逆衝突探索に導入される。
基本的には、弱い秘密鍵のレインボーテーブルを構築し、それらを公開ハッシュと比較し、たまたまその攻撃に含まれるハッシュを持つ人がいることを祈る必要がある。もちろん不可能ではないが、コンピュータが10年で100倍速くなったとしても、どの程度実現可能だろうか？
[編集] OK、もう一度読み直した。公開鍵は秘密鍵から生成されるもので、独立ではない。つまり弱い公開鍵を見つけることだけが問題だ。