On Tue, Nov 2, 2010 at 15:32, Burak Arslan <[email protected]>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 > > > > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
