[zeromq-dev] Encryption (OpenSSL/TLS)

Martin Sustrik sustrik at 250bpm.com
Fri Oct 1 17:36:56 CEST 2010


Matt,

> MANDATORY
> Secure - must use a known secure approach
> Endpoints Only - must not require adding features to the fabric (new
> protocols, forwarders, etc.)  (implies : routable payloads)
> Routable Payloads - end to end protocol must allow payloads to be
> routable "as is"
> No System Features - must not require adding system-level features or
> packages (aside from ØMQ or cognizant applications)
> 	Discussion: ØMQ is a "because it's there" network, which is
> application level only, system upgrades will reduce/eliminate
> applicability
>
> REQUIRED
> Channel Based Encryption - must permit multiple counter-parties /
> channel based encryption without loss of channel security (PubSub)
> Packet Level / Re-orderable - must not require message in-channel
> chaining, etc. (PubSub)
>
> DESIRED
> Reuse Existing Key Distribution - should be able to use existing
> keydist, etc.
> Application Oblivious - don't require applications to be aware that
> crypto is being used
> 	alternative: Configuration Driven - require only that a new
> configuration (such as "crypto://") be used to enable
> Efficient - should not introduce substantial overhead (I'd like to run
> my data feed through this)
> Low Latency - encryption should require e.g. running through a
> pipelined crypto box
> Local Security - local debugger attaches, etc., should not be able to
> compromise the system
> Topic Based Encryption - a single PubSub channel should allow multiple
> encryption streams (permit/deny) by topic
>
> DON'T CARE (do we?)
> Traffic Analysis - if you're obscuring traffic you're in a different
> business, use SIPRNET ;-)
>
> IMPLEMENTATION NOTES
> Crypto in Devices - suggestion - embed crypto in DEVICE framework,
> allowing applications to be (somewhat or fully) oblivious

So what's your conclusion from that?

Martin



More information about the zeromq-dev mailing list