[zeromq-dev] EncryptedSocket added to pyzmq in branch

[MinRK]

On Wed, Nov 3, 2010 at 08:16, Dhammika Pathirana <dhammika at gmail.com> wrote:

> Hi Min,
>
> On Tue, Nov 2, 2010 at 2:40 PM, MinRK <benjaminrk at gmail.com> wrote:
> >
> >
> > On Tue, Nov 2, 2010 at 13:57, Burak Arslan <burak.arslan at arskom.com.tr>
> > 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101103/085bfdfd/attachment.htm>