SSL は、私がやりたいことに対してかなり肥大化しているように見えます。また、私は OpenSSL に対して情熱的な憎しみを持っています (NSS が使用できる可能性があります)。RPC / 暗号化された RPC / イベント ストリーム / 暗号化されたイベント ストリームに使用される 2 つのノード間で TCP チャネルを開く必要があります。プロトコル バッファを使用して、さまざまなトラフィック ソースを定義および多重化しています。
最初から SSL を使用したくありません。暗号化されたイベント ストリームと暗号化された RPC を暗号化および復号化するには、認証された安全なキー確立 (認証された diffie-hellman) と、おそらくブロック暗号ベースのストリーム オブジェクトが必要です。
私が最初に考えたのは、SSL 実装からソケット ハンドルを取得し、それを暗号化されていない交換と暗号化された交換に使用できるという条件で、SSL 実装に基づいて構築することで、コーディング時間と設計時間を節約することでした。しかし、これはおそらく醜い実装になるでしょう。私が知っている限りでは、これを行うと ssl プロトコルと互換性がない可能性があります (つまり、TCP 状態と SSL 状態の間の強い結合)。
私が考えた 2 番目の考えは、複数のソケットを開くことで、コーディング時間と設計時間を節約することでした。しかし、マルチソケット プロトコルの設計が悪いことは誰もが知っていることです。
3 番目の考えは、すべてを暗号化するというものでしたが、問題のサービスは高性能イベント スイッチとして機能し、同じマシン上でデータベース サーバーも実行されています。トラフィックの大部分がクリアテキストになるため、このアプローチのオーバーヘッドは満足できません。
したがって、これらのアプローチは私には満足のいくものではないようです。したがって、cryptpp と boost::asio を使用することで、独自のソリューションを展開し、独自のプロトコルを構築できるという結論に達しました (これは既に行う必要があります)。私は非常に有能なシステム プログラマーであり、暗号化技術の適用を理解しているエンジニアがいます。
私はすべて再利用に賛成です。この場合、SSL を再利用できればいいのにと思いますが、できないと思います。同様の状況での経験 (ネットワーク プロトコルを設計または作業したことがある必要があります) からのアドバイスをいただければ幸いです。私に最も大きな印象を与えるアドバイスがカチカチ音をたてます.:D
ps、私のアプリケーションは、とにかく cryptopp をプルしているエキゾチックな暗号化も実行する必要があります。