[zeromq-dev] EncryptedSocket added to pyzmq in branch
dhammika at gmail.com
Wed Nov 3 16:16:53 CET 2010
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>
>> 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:
> 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:
>> 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.
> 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
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.
More information about the zeromq-dev