アカウント名:
パスワード:
…ので、 PGP のセキュリティが根底から覆ったわけではないけれど、鍵サーバに登録されてしまっていたという点が、信頼の輪に本来入れるべきではないものが入ってしまった点で割と大きい問題…という認識で合ってるかな?
あと、自分が作った鍵なら失効させることができるけど、偽造された鍵だと失効させる方法が無い? ということに気づいた。
ここで書かれている鍵IDというのはフィンガープリントの下位32bitなので、そこだけ一致する鍵が作れるというのは想像に難くありません。リンク先にもありますが、フィンガープリントの一致を確認しろ、に尽きると思います。鍵サーバで複数の鍵がヒットしたら危険信号、とも言えますが、本物の鍵が登録されているとも限らないので過信は禁物です。
通常信頼の輪に鍵サーバは含めないと思います。自分のkeyringに偽造鍵をインポートしない限り大丈夫、と理解しています。
ところで、例に挙がっている偽造鍵はpgp.mit.eduでは失効されているようです。どうやったんだろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
鍵そのものやフィンガープリントが偽造できたわけではない (スコア:0)
…ので、 PGP のセキュリティが根底から覆ったわけでは
ないけれど、鍵サーバに登録されてしまっていたという点が、
信頼の輪に本来入れるべきではないものが入ってしまった点で
割と大きい問題…という認識で合ってるかな?
あと、自分が作った鍵なら失効させることができるけど、
偽造された鍵だと失効させる方法が無い? ということに気づいた。
Re: (スコア:0)
ここで書かれている鍵IDというのはフィンガープリントの下位32bitなので、そこだけ一致する鍵が作れるというのは想像に難くありません。
リンク先にもありますが、フィンガープリントの一致を確認しろ、に尽きると思います。鍵サーバで複数の鍵がヒットしたら危険信号、とも言えますが、本物の鍵が登録されているとも限らないので過信は禁物です。
通常信頼の輪に鍵サーバは含めないと思います。自分のkeyringに偽造鍵をインポートしない限り大丈夫、と理解しています。
ところで、例に挙がっている偽造鍵はpgp.mit.eduでは失効されているようです。どうやったんだろう。