[zeromq-dev] Encryption (OpenSSL/TLS)

[Pieter Hintjens]

Matt, would you chuck this onto the wiki, maybe in the topics category?
On 1 Oct 2010 14:27, "Matt Weinstein" <matt_weinstein at yahoo.com> wrote:
> Folks,
>
> Generally, here's a first shot as far as requirements and
> implementation notes from these emails.
>
> I'm sure I've missed a lot. Please suggest changes/corrections/
> additions/deletions and let's discuss.
>
> Best,
>
> 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
>
> -
> On Oct 1, 2010, at 5:39 AM, Burak Arslan wrote:
>
>> On 10/01/10 11:47, Mikael Helbo Kjær wrote:
>>> As an app-builder trying to make use of zmq as many places as
>>> possible
>>> this is the main problem I have with deploying zmq outside our
>>> firewall really, everything else is acceptable.
>>
>> as an app builder, the main problem you should have with deploying
>> zeromq outside your firewall is that, last time i looked, it is
>> trivial
>> to remotely crash it.
>>
>> http://lists.zeromq.org/pipermail/zeromq-dev/2010-September/
>> 005944.html
>>
>> burak
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101001/f0b01661/attachment.htm>