[zeromq-dev] EncryptedSocket added to pyzmq in branch

Brian Granger ellisonbg at gmail.com
Tue Nov 2 14:34:20 CET 2010

On Tue, Nov 2, 2010 at 3:53 AM, Burak Arslan <burak.arslan at arskom.com.tr> wrote:
>  On 11/02/10 10:31, Min RK wrote:
>> There's no encrypted bit or anything. This isn't 'Encrypted ZMQ', it's just an object that encrypts messages prior to sending them. Think of it more as a wrapper than anything.  The messaging library has no sense of whether a message is encrypted or not, you have to specify that in user code:
>> a.send(msg, encrypt=True)
>> must be matched with:
>> b.recv(decrypt=True)
>> Otherwise b would just receive the encrypted buffer, which is perfectly valid, if for instance b is just going to relay it to c without looking at it, and c is the real destination.
> objections:
> 1) this has nothing to do with zeromq. so it shouldn't be part of the
> python zmq package. i suggest creating a package like zmq.patterns and
> moving it there.

Our approach with pyzmq is divide the cosebase into a "core"
subpackage that only has the python bindings to the zmq library, and
then other subpackages that add capabilities on top of that.  For
example, we have an eventloop and loggin subpackage that provide a
simple event loop or pyzmq and pyzmq enabled tools for python's
logging module.  The same is true of the encryption stuff, it is not
in the core.  We simply don't have the manpower to start separate
projects for each things like this, nor do we want to have projects
that depend pyzmq ha

> 2) it can't tell ciphertext from plaintext. as previously mentioned,
> this ability requires changes to the wire-protocol. if security-related
> changes are to be introduced, i'd prefer to start at socket identity
> signing. (a la dnssec) you can imagine that this is a HUGE can of worms,
> and i think zeromq has much more security-related problems until we come
> to that.

I don't quit see how this follows.  In all the cases that we plan on
using it, we simple write our endpoint logic to know when it should
expect encrypted data and when it should not.  Most of the time,
everything will be encrypted, so no decisions will have to be made.
Also, data that doesn't match the expectation will fail our
deserialization attempts and we will just reject it.

> on a related note, i also strongly advise against simply using
> encryption without signing because you can't detect data corruption. in
> cbc-like encryption modes, this means one bit flip can corrupt the
> entire message, and you won't be able to detect it.

Yes, we definiitely cannot detect data corruption.  But, this is no
worse than a regular 0MQ connection, so minimally, we are not making
the situation worse.

> 3) it's redundant. decent serialization protocols already (properly)
> support such schemes. see my previous post from a related thread.

This has nothing to do with serialization.  In most of our
applications, we have a completely orthogonal serialization layer like
JSON, Python's pickle, etc.  Here is a picture:

Serialize -> Encrypt -> send ========= recv -> Deencrypt -> Deserialize

Also, if the data is corrupted, then the Deserialize step will fail
and we will simply reject the message.

> so my vote is towards reverting that change, or at worst moving it to a
> separate package.

We appreciate your feedback.



> regards
> burak
> _______________________________________________
> 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

More information about the zeromq-dev mailing list