web-dev-qa-db-ja.com

GPGを使用して、サードパーティはメッセージが特定の公開鍵で暗号化されていることを確認できますか?

ボブはメッセージXをアリスに送信しています。彼はgpgを使用してアリスの公開鍵でXを暗号化し、彼女の暗号化されたメッセージ(暗号文)を送信します。

後にアリスは、ボブがミスを犯し、暗号文は彼女の公開鍵で作成されなかったと主張します。

ボブは、暗号化されたメッセージが実際にアリスの公開鍵で暗号化されていることをサードパーティに証明できますか?

結果の暗号化されたメッセージは、メッセージXが同じであっても毎回異なります( 同じファイルをGnuPGと同じ鍵で暗号化すると同じ暗号文が生成されますか? )。サードパーティはそれを暗号化できません再び比較結果。他に方法はありますか?

可能であれば、既存のソフトウェアでこれを実行する方法をコマンドに指定してください。

編集:アリスは協力していません。 Xをサードパーティに公開することができます(ただし、可能であればそれなしでより良い)

2
urza.cc

番号。

秘密鍵がわからない場合、プレーンテキストメッセージがわかっていても、PGP暗号化メッセージが特定の公開鍵で暗号化されているかどうかを確認する方法はありません。

2
user186505

たぶん一種の

PGPのpk-encrypted-skパケット( rfc4880 5.1 を参照)には、通常、受信者の鍵の64ビットの「長い」キーIDが含まれています。これは、受信者が複数の受信者に暗号化されている場合、正しい復号化キーを使用して、受信者が自分に向けたタグ1パケット(存在する場合)を識別するのに役立つことを目的としています。必要に応じてゼロに置き換えることで抑制できます。これは、gpg --list-packetsを含む、任意の数のPGP分析/デバッグツールで表示できます。

ボブが、メッセージの送信についての不正行為や嘘についてではなく、間違いについてのみ非難され、GnuPGの--hidden-recipientなどを使用しなかった場合、これでおそらく十分です。ボブが(寄与の)違法行為で非難された場合、メッセージが送信されたとき(または少なくとも紛争の前に)署名したか、TSAによってタイムスタンプが付けられたか、またはその両方である場合に役立ちますが、もっと多くのことケースまたは処理する可能性のあるケースの範囲についての詳細。 (ObSecStack:あなたの脅威モデルは何ですか?)

キーBLOBがまだ利用可能であるか、取得できると仮定します。キーサーバーから、これはボブが使用したキーをほぼ「証明」します。長いキーIDに対して偽のキー(2番目のプリイメージ)を生成することは、現在では困難ですが不可能ではありません。 (手動の選択または「検証」でよく使用される32ビットの「短い」keyidは簡単です。 https://evil32.com を参照してください。 )64ビット用のcollisionsを生成することは現実的ですが、それを行うには、アリスが誤った主張で意図的に共謀する必要があります。脅威モデルについては上記を参照してください。

ただし、これは、使用されたキーがアリスのキーであった(または現在もそうである)ことを証明するものではありません。ボブが実際にミスを犯した可能性は十分にあります。暗号化するキーを選択する際にどのような理由または証拠を使用しましたか?

  • アリスの名前が入った鍵を持っているだけでは、それが彼女の鍵であるという証拠にはなりません。それらは偽造するのは簡単です。

  • 信頼できる他の当事者によって署名されたアリスの名前が含まれた鍵を持っていることは、より良い証拠ですが、絶対的なものではありません。偽の鍵に署名するように誰かがアリスを装った可能性があります。

  • アリスが実際にボブにこのキーを与えたとしても、彼は(1)彼女がそうしたこと、そして(2)その後いつでも他人が改ざんできなかったデバイスまたはストレージでそれを維持したことを証明できますか?

注: メッセージの暗号化に使用された公開鍵を証明することは可能ですか? と同様です。これは、PGPだけではなく、より広い範囲をカバーしています。また
自分のGPGメッセージを暗号化した後、誰が復号化できるかを確認できますか?
OpenPGP暗号化ファイルから漏洩する情報は何ですか?
PGP暗号化メッセージのすべての(その他の)受信者を識別できますか?
以前は見なかった。

3