[zeromq-dev] EncryptedSocket added to pyzmq in branch

[MinRK]

Here's how we arrived at the EncryptedSocket:
1. Someone wants to hide message content, but use zeromq today
2. Network-level security is unavailable (for whatever reason, but
frequently true)
3. If you have a messaging system that doesn't support any security *at
all*, what's the simplest model, assuming you have no control between send
and recv?

Asking that, we came upon: encrypt then send / recv then decrypt

Since PyCrypto is the standard tool for encryption in Python, we supported
their interface, but any object that provides that extremely basic interface
can be used.

Note that we *have not* added any security to zeromq, nor are any encryption
schemes included in pyzmq.  Simply a wrapper that allows you to use *any*
encryption more conveniently than manually calling encrypt/decrypt each
time.  There's a reason it's called 'EncryptedSocket', not 'SecureSocket' -
it sends encrypted messages, that is all.

Now, to be productive:

Is there a better model for hiding message data using an unmodified current
release version of zeromq, which means that zmq_send and zmq_recv are black
boxes, and are assumed to be operating on an untrusted network? Because that
is the situation we currently face, until zeromq itself starts supporting
security internally.

Thanks,
-MinRK

On Tue, Nov 2, 2010 at 11:47, Pieter Hintjens <ph at imatix.com> wrote:

> On Tue, Nov 2, 2010 at 7:34 PM, Burak Arslan <burak.arslan at arskom.com.tr>
> wrote:
>
> >> This goes into the "I'd love feature X!" bucket.  The response is,
> >> "Great idea, I'm looking forwards to seeing how you do this".
> >
> > um, 'git rm core/crypto' ?
>
> Yes, of course :-)  But that simply creates a fork.  The real work
> with any FOSS project is then convincing people to use your fork, and
> maintaining it.
>
> > i also falsely assumed you exercised a more close control over the
> > bindings, but that's not really related.
>
> FOSS is like little fluffy birdies, hold them too tight in your hands
> and they die.
>
> No, we do not exercise control over any aspect of the project except
> those parts we write ourselves, and "we" means every owner of every
> subproject.  I.e. you want to own part of 0MQ, you make / improve that
> part sufficiently.
>
> -Pieter
> _______________________________________________
> 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/20101102/ca9f5ff0/attachment.htm>