[zeromq-dev] Encryption (OpenSSL/TLS)

[Brian Granger]

On Thu, Sep 30, 2010 at 4:57 PM, Steve Atkins <steve at blighty.com> wrote:
>
> On Sep 30, 2010, at 4:33 PM, Blair Bethwaite wrote:
>
>> Hi list,
>>
>> We're experimenting with zmq at the moment and I've been thinking a
>> little about this general issue too...
>>
>> On 1 October 2010 05:05, John Flanagan <flanagan.ffs at gmail.com> wrote:
>>> There are three overall approaches:
>>>
>>> 1) VPN level encryption, handled UNDER zmq.
>>> 2) SSL level encryption, handled BY zmq
>>> 3) message level encryption, handled ON TOP OF zmq.
>>
>> Succinct summary. I'd like to add a couple of talking points:
>> Option (1) is clearly the most robust solution, however _deploying_ it
>> in the wild is not so easy. In our use case we can only expect to have
>> administrative access to one box in a large connected system running
>> over heterogeneous systems. If anyone knows of a good way to create a
>> static-linked binary including transparent VPN under zmq we'd love to
>> hear about it.
>> Option (3) should be considered weak. Even assuming key-negotiation
>> etc. can be handled out-of-band easily, this approach is still open to
>> man-in-the-middle and replay attacks which could break or cause
>> serious disruption to the system.
>
> Option 3 needn't be weak. It can use cryptography as strong as that
> in ssl, or stronger, and can certainly be made immune to man in the
> middle or replay attacks. It can all be done in-band, though it
> needs PKI of some sort unless you have a shared secret.

But that is a lot of work to get something that TLS gives you for free
(OK, not quite for free)...

> I'm looking at doing it this way for an app I'm working on, based on
> a shared secret between the two peers, and it doesn't look too painful
> to do securely (PAKE, basically). I'm only concerned about protecting
> payloads - traffic patterns aren't something I need to obscure.
>
> It does require a lot more work than options 1 or 2, though, and
> there's a lot more potential for making a bad crypto mistake in
> there.
>
> Cheers,
>  Steve
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com