> 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.
But then doesn't that mean that all of our helper methods like: send_multipart recv_multipart send_json recv_json send_unicode recv_unicode All have to have *_encrypted_* versions? I think that is a bit excessive and am fine with using a keyword argument that is passed along like flags is currently. > 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 This is well put. Cheers, Brian > -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 > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
