On Wed, Nov 3, 2010 at 08:16, Dhammika Pathirana <[email protected]> wrote:
> 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. > I have changed no bindings. This is a *new* object that allows you to conveniently do encrypt&send. I did change send(..., encrypt=True) to send_encrypted(...), so it looks more like existing extensions in pyzmq. This and stunnel address different problems. In general some of the differences between message-level encryption and transport-level encryption: Transport: encrypt/decrypt happen at each zmq hop Message: only decrypt at endpoints (big deal for many relay hops) Transport: always encrypt everything Message: can encrypt only the sensitive subset of traffic -MinRK > > Dhammika > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
