[zeromq-dev] EncryptedSocket added to pyzmq in branch

[Burak Arslan]

 On 11/02/10 15:34, Brian Granger wrote:
> 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
>


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.

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.

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.


>> 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