c++ - RFC /advice: On secure/unsecure rpc/event-stream protocol design -

ssl seems quite bloated want do, , have passionate hatred openssl (nss might useable). need open tcp channel between 2 nodes used rpc / encrypted rpc / event streams / encrypted event streams. using protocol buffers define , multiplex different traffic sources.

i don't want use ssl start with. need authenticated secure key-establishment (authenticated diffie-hellman) , perhaps block-cipher based stream object encypher , decypher encrypted event streams , encrypted rpc.

the first thought had was, save coding time , design time building on ssl implementation, provided can socket handle ssl implementation , use unencrypted exchanges encrypted exchanges. end ugly implementation, , know doing might incompatible ssl protocol (i.e., strong-coupling between tcp state , ssl state).

the second thought had was, save coding time , design time opening multiple sockets. know multi-socket protocol design evil.

the third thought was, i'll encrypt everything, service in question serves in capacity of high performance event switch , has database server running on same machine well. overhead of approach doesn't satisfy majority of traffic cleartext.

so, these approaches don't seem satisfactory me. therefore, have come conclusion using cryptopp , boost::asio can roll own solution , construct own protocol (which have do). pretty capable systems programmer , have engineers understanding applying encryption techniques.

i reuse, , in case wish reuse ssl, don't think can. advice can give me experience in similar situations (you must have designed or worked on network protocol) appreciated. advice makes biggest impression on me gets tick.:d

p.s., application needs perform exotic encryption pulling in cryptopp anyway.

you can re-use ssl - there no untoward coupling tcp state. can use ssl on underlying stream like, dependency must two-way.

the simplest way use ssl library allows provide own send/receive functions called ssl library when has encrypted-side data send or receive. implement these functions wrapping ssl data within special frames within own underlying protocol.

(i familiar how openssl library - ssl_set_bio() function - sure other ssl implementations allow similar).

note though computation overhead of key-agreement part of protocol - whether done through ssl or roll-your-own - far outweigh actual block cipher encryption/decryption, "encrypt everything" may not of loss expect.