[zeromq-dev] EncryptedSocket added to pyzmq in branch

Dhammika Pathirana dhammika at gmail.com
Wed Nov 3 16:16:53 CET 2010


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.


Dhammika



More information about the zeromq-dev mailing list