サーバー ソフトウェアからクライアント ソフトウェアにデータを送信したいのですが、サーバー (プライベート ソフトウェア) だけがその特定のデータを暗号化でき、クライアントはそれを復号化できるような方法で暗号化します。
最初は RSA が解決策になると思っていましたが、私が理解しているように、逆方向に使用したいと考えています。サーバーで公開鍵を使用してデータを暗号化し、クライアントで秘密鍵を使用して復号化できます。誰かが秘密鍵から公開鍵を導出できることを除けば、それは問題なく機能します。あれは正しいですか？もしそうなら、代替オプションはありますか？
前もって感謝します。
やりたいことは、サーバーが送信するデータにデジタル署名することです。すべてのクライアントは、このデジタル署名を検証して、サーバーだけが作成した可能性があることを証明できます。
サーバーはデータのハッシュを計算し、サーバー上の秘密鍵 (署名鍵) を使用してハッシュを暗号化します。次に、サーバーはメッセージ (プレーン テキスト) とハッシュをクライアントに送信します。クライアントが 2 つのデータを取得すると、サーバーの公開鍵 (Verify Key) を使用して暗号化されたハッシュを復号化します。これで、クライアントはプレーン テキスト メッセージ自体のハッシュを計算し、それをサーバーが送信したハッシュと比較できます。2 つのハッシュが一致する場合、クライアントはメッセージがサーバーから送信されたものであり、他のユーザーから送信されたものではないことを認識します。
注: メッセージはプレーン テキストで送信されるため、このシステムには機密性がありません。この署名メカニズムは、完全性と信頼性のみを保証します。機密性も必要な場合は、プレーン テキストで送信する代わりに、従来の暗号化を使用してメッセージを暗号化できます。
TLSはこのようなことを行うため、TLS をデータ チャネルとして使用することを検討してください。
要件は、サーバー側認証とも呼ばれるTLSの一方向認証モード（以前のSSL）の教科書の説明です。基本的に、それはあなたがhttpsWebサイトにアクセスするたびに起こることです。
しかし、httpsについて知っていると仮定すると、通信しようとしているのはhttpデータではなく、他のプロトコルだと思います。ここでTLSが優れています。TLSはトランスポート層に実装されているため、アプリケーションデータプロトコルに依存せず、TLSで暗号化/認証されたソケットを介して任意のデータを送信できます。
TLSはバトルテスト済みであり、安全なトランスポートプロトコルで得られるものとほぼ同じです。自分で作成するものはすべて、安全性が低くなる可能性が非常に高くなります。安全なプロトコル設計は、正しく行うのが最も難しいものの1つです。