暗号化された通信を可能にするために、サーバーがユーザーの公開鍵をパートナーに提供していると想像してください。ただし、サーバーは秘密鍵にアクセスできません..
とにかく-サーバーがハッキングされ、要求された公開鍵が送信されないことを想像してください。
Alice が Bob の公開鍵を要求する
サーバーがEve の公開鍵を送信するBob が Alice の公開鍵を要求する
サーバーがEve の公開鍵を送信するAlice は Bob にメッセージを送信します
サーバーはメッセージをアンパックし、それを読み取り、再パックします -> Bob に送信します...Bob はメッセージを Alice に送信します
サーバーはメッセージをアンパックし、読み取り、再パックします -> Alice に送信します...
私の質問は、そのような虐待を防ぐ方法は? アリスがボブの公開鍵を使用していること、およびその逆をどのように確認できますか?
あなたが今提案した計画の下では、あなたはできません。ここでの鍵（しゃれは意図されていません）は、鍵の有効性を検証するために使用される方法が危険にさらされた場合、あなたは負けるということです。
SSLは、署名チェーンを作成することでこれを回避しようとします。一部のキー（非常に注意深く保護され、他の方法で検証されます）は、別のキーに署名し、別のキーに署名し、アリスのキーに署名します。チェーンの各ステップを検証することで、（原則として）チェーンが有効であることを知ることができますが、チェーンのいずれかのステップに沿った秘密鍵が危険にさらされると、失われます。
PGP（別名GPG）は、別の、しかし同様の方法で問題を解決しようとします。キーは、他の任意の数のキーで署名でき、グラフ（Web of Trustと呼ばれます）を形成します。有効であることが確認されたいくつかのキーを選択します。たとえば、それらを直接確認し、信頼できるものとしてマークします。次に、Nステップ未満（および/または異なる信頼されたルートからのM個の個別のパスから）到達可能なキーも有効と見なされます。
あなたが本当にパラノイアであるならば、もちろん、あなたは他の人に鍵を物理的に渡すことができます。もちろん、彼らはそれがあなたに変装した誰かではないことを確認する必要があります...
とは言うものの、キーの有効性を検証する唯一の本当に確実な方法は、自分でキーを生成することです...ハードウェア/OS/コンパイラ/頭脳も危険にさらされていない限り:)
ここで欠落している重要な部分は認証です。アリスは、彼女が実際にボブの公開鍵を使用していることを知る方法を必要としています。1つの方法は、個人的にキーを交換することですが、それが常に可能であるとは限りません。
それがWebofTrustの目的です。他の当事者は、この鍵がユーザーのものであると確信している場合、ユーザーの公開鍵に署名できます。（信頼できる）他の連絡先の十分な数（3）がボブの公開鍵に署名した場合、それが彼の鍵であると比較的確信できます。
これは、公開鍵暗号化の主な問題です。受け取った公開鍵が実際に目的の受信者の公開鍵であることを確認する方法はありません。HTTPS / SSLがこれを回避する方法は、信頼できる認証局を使用することです。認証局は、問題の当事者の公開鍵に秘密鍵で署名し、認証局に提供されてから公開鍵が変更されていないことを保証します。それでも、要求時に提供されるキーは、認証局に最初に提供されたものと同じであることが保証されます。ただし、これらの証明書を提供するサーバーが危険にさらされている場合でも、問題が発生します。サーバー自体が危険にさらされている場合、上記のようにサーバーにキーに署名させることでさえ、絶対確実ではありません。
PGP（Pretty Good Privacy）のFAQで、この問題について説明しています。
また、これらのトピックの「友好的で消化しやすい」議論については、ブルース・シュナイアーの優れた本「AppliedCryptography 」を読むことをお勧めします。