On Nov 2, 2010, at 8:51, Burak Arslan <[email protected]> wrote:
> On 11/02/10 15:34, Brian Granger wrote: >> 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 >> > > > this is my mistake, i thought the patch went into core/socket.pyx. it > really went into its own module. > > but, i insist that this should be removed from the official pyzmq package. This isn't in the official pyzmq, it's in my branch, as mentioned in the original post. Hence the post here, to receive input. > > 1) it's a functionality that core zeromq, nor no other zeromq bindings > have. you can always maintain your own fork in your own personal github > account, but the one in github.com/zeromq should only be a pure wrapper > for the zeromq, nothing more. pyzmq is really two things: zmq.core: python bindings for zmq and anything not in zmq.core is additional functionality built on top of zmq, such as special devices, logging handlers, etc. > > 2) the proposed encryption scheme is not only useless, but it's > dangerous (see below) this is bad advertisement for a library that has > two hours spent for every single line of code. We don't propose an encryption scheme at all. We just added an object that performs an arbitrary user-specified transform to messages before/after passing them to zmq. it's up to the user to pick a good one. > > >>> 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. >> > > > detecting formats are useful because intra-node networks tend to be > trusted. thus you'll save cpu-cycles by avoiding unnecessary encryption. > and if the numbers you reported are correct, i think you'd waste too > much for unnecessary encryption. > > >>> 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. > > i'm sorry brian but this is nonsense. > > normally, one bit flip is just that, one flipped bit. it's local, it > stays where it is. if you're transporting e.g. voip frames, it's won't > even be audible. > > but a bit flip in a chain-encrypted stream messes up *everything* that > comes after. > > yes, your deserializer can notice this if you're transporting tightly > structured data, and if you're lucky. but if you're transporting a > stream of numbers, or that bit flip happens where you have arbitrary > data in your structure, you won't detect anything. > > not convinced? read how a single bit flip in a handful of messages took > the entire amazon service infrastructure down: > > http://status.aws.amazon.com/s3-20080720.html > > """ > (...) > > More specifically, we found that there were a handful of messages on > Sunday morning that had a single bit corrupted such that the message was > still intelligible, but the system state information was incorrect. > > (...) > """ > > so, my friendly advice: stop relying on your parser for message > validation. that's not its purpose. > >>> 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. >> > > no, sorry, this has everything to do with serialization. in fact, what > you're doing is extending the json (or pickle) standard via Brian & Min > Encryption Scheme (TM). > > by my above definition, json and pickle are not "decent" protocols. they > have advantages like compactness and speed, but security is definitely > not one of them. > > by my above definition, soap is a decent protocol. yes it's slower and > much more complex, but that complexity has sound real-world > justifications. a wss-compilant soap message is validated > cryptographically, not by the xml parser. that way, you can be > reasonably sure that *every bit* received is what the originator meant > to send. > > please accept my apologies if the above is too harsh. i'm just trying to > help. > > best regards, > burak > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
