[zeromq-dev] EncryptedSocket added to pyzmq in branch

[Burak Arslan]

 On 11/03/10 01:21, MinRK wrote:
>
>
> On Tue, Nov 2, 2010 at 15:32, Burak Arslan <burak.arslan at arskom.com.tr
> <mailto: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?
>

first, in my experience, no pure-python solution takes security very
seriously -- you need some c modules one way or the other. i guess
that's mainly for performance reasons.

i will suggest xml. you can use lxml's objectify along with pyxmlsec to
get a rock-solid secure serialization scheme. see an example here:
http://pyxmlsec.labs.libre-entreprise.org/index.php?section=examples&id=10

if xml is not appropriate for you one way or the other, i suggest you
encapsulate encrypted data in your favourite serialization scheme, and
NOT encrypt the serialized byte stream. the way xmlsec does it is right.

you can e.g. use an EnryptedObject or ClearObject to encapsulate your
data  when pickling. after unpickling, you can have 
EncryptedObject.decapsulate() handle decryption for you, whereas
ClearObject.decapsulate() just returns what it received.

you should see better now why having a zmq.crypto package is totally
unnecessary.

if efficiency is a concern during the packing / unpacking of numpy
arrays, you can wrap it the same way inside a simple numpy data
structure that carries codec information like encryption scheme used.
(i.e. clear, aes, aes+hmac-sha, public key etc)

in short, extend your serialization scheme to carry encrypted data via
encapsulation. don't encrypt the serialized byte stream.

i hope that helps.

burak


> 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/20101104/4e082a67/attachment.htm>