[zeromq-dev] EncryptedSocket added to pyzmq in branch

[MinRK]

On Tue, Nov 2, 2010 at 15:32, Burak Arslan <burak.arslan at arskom.com.tr>wrote:

>  On 11/02/10 23:40, MinRK wrote:
> >
> > Thanks for all the notes, they will be very helpful in codes that use
> > the EncryptedSocket.  Note that all of the schemes you propose are
> > fully supported by the EncryptedSocket, in that the *user* tells the
> > EncryptedSocket how to encrypt/decrypt messages. We haven't programmed
> > any encryption, and certainly wouldn't roll our own. We simply present
> > an object that allows users to conveniently use the encryption scheme
> > they have chosen, regardless of how good or bad it may be.
> >
>
> i'll reiterate my points one last time, because i get the impression
> that i still am not communicating them properly:
>
> 1) i did not say EncryptedSocket did not support such-and-such
> encryption scheme.
>

Okay, glad we are clear.  I guess I was confused, since many of your points
seemed to be for/against
particular encryption schemes, which isn't relevant to this object.


>
> 2) i am against it because it doesn't belong in pyzmq, but in whatever
> serialization protocol you're using. if the protocol doesn't support
> security, it's time to switch to one that does, instead of implementing
> hacks over other hacks. that's because proper serialization protocols
> will let you distinguish and switch between various levels of
> cryptographic security transparently, which in turn will let you have
> performance advantages by using cryptography only when it's needed.
>

Point well taken. I think this is the main thing I was missing.  What
existing serialization schemes in Python support encryption?

Currently in IPython we are using JSON in some places (for HTML
portability), and pickle for sending arbitrary objects.
We also support sending raw buffers of things like numpy arrays.

Clearly, for security and efficiency, we could replace JSON and/or pickle
with a
secure serialization scheme, but I'm not aware of any. Do you know of some?

The buffer-interface objects are another matter: What is there to do, given
an already sendable buffer,
but encrypt it? How would such a system differ from just using a cipher to
encrypt the buffer (assuming the cipher
was a Good One with signing and everything)?


>
> 3) i'm against it because it doesn't promote the right way of doing
> things. that's a direct consequence of the above.
>

Certainly, if there are good serialization+security tools for Python,
especially in the standard library, they would be preferable to
having separate serialization and security. However, from a starting point
of a bunch of sendable buffers, I still don't see the difference between
just encrypting bytes and serializing+encrypting bytes.


>
> 4) if indeed you use it, be sure to adopt a verification scheme like
> hmac, because a single bit flip inside a chain-encrypted byte-stream
> will have disastrous consequences for your data, especially when it's
> binary.
>

Thanks for pointing us to this. We don't know much about security, and have
used other people's tools
that abstracted the specific scheme being used until now. That's why we
specifically added an object that doesn't make
any security decisions for you; it only makes using your own security
choices more convenient.


>
> 5) my spending all this time explaining you the consequences of your
> actions has absolutely zero tangible benefit to me.


I appreciate your time, and you certainly don't need to continue wasting it
answering my questions.


> i don't care if you
> keep EncryptedSocket inside pyzmq because you've taken care to make it
> unobtrusive -- it doesn't interfere with my use case at all.
>

Yes, we would never make the base zmq.Socket behave differently than other
bindings. Sorry for any misunderstanding
on this point.


>
> so this is not a "strong demand" or anything to do my bidding. do
> whatever floats your boat.
>
> i certainly hope we on the same page now.
>

Yes, I think we are.

Thanks for the input!
-MinRK


>
> burak
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101102/5a3481ab/attachment.htm>