Hi Min, On Tue, Nov 2, 2010 at 2:40 PM, MinRK <[email protected]> wrote: > > > On Tue, Nov 2, 2010 at 13:57, Burak Arslan <[email protected]> > wrote: >> >> On 11/02/10 21:27, MinRK wrote: >> > Is there a better model for hiding message data using an unmodified >> > current release version of zeromq, which means that zmq_send and >> > zmq_recv are black boxes, and are assumed to be operating on an >> > untrusted network? >> >> first, two warnings: >> >> 1) the zeromq-2.0.10 release is still remotely crashable, so you need a >> trusted network. encryption does not make sense in a trusted network. >> >> 2) i have no idea about your environment, requirements and resources. >> what i say may sound funny, may be too python-centric, or just the wrong >> thing to do in your case. >> > >> >> if you consider key distribution solved, > > We certainly don't, and have historically left key distribution in IPython > up to the user, via shared filesystem or manual scp. > >> >> just use hmac + aes to >> signcrypt the messages. pycrypto supports both. > > This appears to be an example of what you describe: > http://code.activestate.com/recipes/576980-authenticated-encryption-with-pycrypto/ > That object provides the encrypt/decrypt interface, and is thus fully > supported by EncryptedSocket. Remember, we make exactly zero choices for the > user about encryption, so selecting a scheme is not relevant to the > EncryptedSocket object itself, which is entirely oblivious to the chosen > scheme, but is very relevant for users of the object (very helpful for > IPython, thanks!). > >> >> if you also need to do key distribution, i'd try to work with a pgp >> implementation first. gpgme and thus pyme is slow and difficult to >> deploy, but you'd be safe. >> >> also see the m2crypto page. it claims to have pgp support. >> http://chandlerproject.org/Projects/MeTooCrypto. the library list there >> is also interesting. >> >> here's a relevant topic: >> >> http://stackoverflow.com/questions/1020320/how-to-do-pgp-in-python >> >> if those solutions are not efficient enough, you have many options. >> simplest is poor man's pki: >> generate a secret, hardcode it in your application and use it for >> signcrypted key-exchange. you can do this with public key cryptography >> if you know how it works. you can make it so everybody agrees on a >> different key on first contact. >> >> but try very hard to get pgp working before you try your own methods. > > We will definitely keep this in mind for IPython. > >> >> hth >> burak > > > 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. > The starting point, where the EncryptedSocket comes into play, is when the > user already has a cipher that knows about your encryption. This means that > by the time an EncryptedSocket gets instantiated key generation and > distribution has already happened, and was handled by the instantiating > application.
Why don't we use stunnel? I suppose it'll add some latency but it'll be totally transparent and won't need binding changes. Dhammika _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
