On Tue, Nov 2, 2010 at 3:53 AM, Burak Arslan <[email protected]> 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. Cheers, Brian > regards > burak > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
