クライアント サーバーのシナリオを検討すると、次の 2 つのオプションがあります。
どちらがより安全な方法ですか? また、公開鍵がクライアント CA ストアなどのストアから取得される場合はどうなりますか? クライアントアプリでバインドするよりも安全ですか?
展開はインストーラーを介して行われ、実行のたびにバージョンが確認されます。
（のみ）DH鍵交換を使用すると、クライアントは、それが実際に通信しているサーバーであることを知る方法がありません。
したがって、会話は盗聴者からは安全ですが、誰かがサーバーのふりをしてクライアントを危険にさらす可能性があります。
しないでください。
本番コードでこの種の問題を解決する必要がある場合は、専門家に依頼してください。暗号化には非常に多くの微妙な落とし穴があるため、クロッパーになる可能性があります。
公開鍵のシナリオでは、クライアントが鍵を生成する必要があり、この鍵が安全に生成されていることを確認する方法はありません (誰かがシステムにアクセスして、常に同じ値を使用するように鍵ジェネレーターを変更し、前の値をインクリメントする可能性があります)。値が 1 ずつ、攻撃者があなたの通信をこれまで以上にドロップする可能性があると述べています)。公開鍵暗号は、この目的のために設計されたものではありません。
Diffie-Hellmanの方が良いでしょうが、Tobiasが言ったように、自分でロールすると、おそらく攻撃を残すでしょう.
秘密鍵アルゴリズムは通常、対応する公開鍵よりも優れたパフォーマンスを提供します (私が覚えている限りでは 1 桁以上)。その意味で、Diffie-Hellman は、クライアント サーバー アーキテクチャの RSA よりも効率的です。
サーバーよりはるかに多くのクライアントがある場合は、公開鍵アルゴリズムを実装してそれらの間の交換を減らすことができます。
それでも、多くの人が言ったように、さまざまな種類の攻撃があるため、この問題について専門家に尋ねる/雇うことを検討する必要があります (ほとんどの攻撃は、アルゴリズム自体ではなく実装のみを対象としています)。それでも続行したい場合は、幸運を祈るとともに、慎重に読む必要があるこのリソースを紹介します。
Tobias が上で述べたように、独自のプロトコルを作成しない方がよいでしょう。TLS の実装を使用するか、少なくとも TLS でプロトコルをモデル化することをお勧めします。TLS は、Diffie-Hellman と証明書ベースの鍵交換の両方のオプションを提供します。