Skip to main content

Driveby contribution to Python Cryptography

While at PyConAU 2016 I attended the Monday sprints and spent some time looking at a proposed feature I hoped would soon be part of cryptography. As most readers of this blog will know, cryptography is a very respected project within the Python ecosystem and it was an interesting experience to see how such a prominent open source project handles contributions and reviews.

The feature in question is the Diffie-Hellman Key Exchange algorithm used in many cryptography applications. Diffie-Helman Key Exchange is a way of generating a shared secret between two parties where the secret can't be determined by an eavesdropper observing the communication. DHE is extremely common - it is one of the primary methods used to provide "perfect forward secrecy" every time you initiate a TLS connection to an HTTPS website. Mathematically it is extremely elegant and the inventors were the recipients of the 2015 Turing award.

I wanted to write about this particular contribution because many people seem to expect that the only open source contributions are writing code, and also I wanted to highlight that good things take time!
So at PyConAU; I knew that a cryptography contributor Aviv Palivoda had opened a pull request in May #2914 and I wanted to see if it was going to work for my purposes and if I could help push it along!

One great feature of pip is that you can install directly from a git branch, so in a new virtual environment installing from the pull request's source was as easy as adding a new line to my requirements file:

-e git+https://github.com/palaviv/cryptography.git@dh-impl-2#egg=cryptography

After a pip install we now can import the modified version of cryptography and test the new feature. The details aren't relevant for our purposes here so I'll skip the client test code. My simple script tested my understanding of the new DHKE api. After I got everything working I provided my feedback on the PR - I'd identified a few small inconsistencies in the documentation.

The author palaviv responded and invited me to carry out some of the suggested changes. To do this I added a few commits (via a PR) to his branch which, when accepted, propagated to the PR on the main cryptography repository. These were small updates like this:


While waiting for a formal review there were a few automated checks that needed to pass: documentation tests had to build and run in a reasonable time, code coverage had to be 100% etc. The github project is setup to automatically carry out these small number of checks before a PR can be merged:



Before too long, in early November, reaperhulk (Paul Kehrer) carried out an in-depth code review and raised further concerns which palaviv addressed in short order. It looks like all the checks are passing and the code review will soon be signed off meaning the new feature is ready to land in master. All going according to plan it is scheduled to be released in cryptography version 1.7 which should be out in December.

Not every contribution to open source has to be writing code, and not every contribution will be accepted straight away. My intention when I started to look at this PR was just to see how it worked and perhaps just by commenting give it a bump in attention. In fact palaviv based it off an earlier, rejected, pull request made by someone else. Open source is full of stories of people picking something up and running with it.

I really enjoyed seeing this feature evolve, and playing a small part. Finally I'd like to say how very impressed I am by the dedicated individuals on the cryptography team for keeping high standards ensuring quality software is produced. As you would expect from a project like cryptography every new feature or major change clearly gets vetted with a very careful code review.

Popular posts from this blog

Bluetooth with Python 3.3

Since about version 3.3 Python supports Bluetooth sockets natively. To put this to the test I got hold of an iRacer from sparkfun . To send to New Zealand the cost was $60. The toy has an on-board Bluetooth radio that supports the RFCOMM transport protocol. The drive  protocol is dead easy, you send single byte instructions when a direction or speed change is required. The bytes are broken into two nibbles:  0xXY  where X is the direction and Y is the speed. For example the byte 0x16 means forwards at mid-speed. I was surprised to note the car continues carrying out the last given demand! I let pairing get dealt with by the operating system. The code to create a  Car object that is drivable over Bluetooth is very straight forward in pure Python: import socket import time class BluetoothCar : def __init__ ( self , mac_address = "00:12:05:09:98:36" ): self . socket = socket . socket ( socket . AF_BLUETOOTH , socket . SOCK_STREAM , socket .

Matplotlib in Django

The official django tutorial is very good, it stops short of displaying data with matplotlib - which could be very handy for dsp or automated testing. This is an extension to the tutorial. So first you must do the official tutorial! Complete the tutorial (as of writing this up to part 4). Adding an image to a view To start with we will take a static image from the hard drive and display it on the polls index page. Usually if it really is a static image this would be managed by the webserver eg apache. For introduction purposes we will get django to serve the static image. To do this we first need to change the template. Change the template At the moment poll_list.html probably looks something like this: <h1>Django test app - Polls</h1> {% if object_list %} <ul> {% for object in object_list %} <li><a href="/polls/{{object.id}}">{{ object.question }}</a></li> {% endfor %} </ul> {% else %} <p>No polls

Homomorphic encryption using RSA

I recently had cause to briefly look into Homomorphic Encryption , the process of carrying out computations on encrypted data. This technique allows for privacy preserving computation. Fully homomorphic encryption (FHE) allows both addition and multiplication, but is (currently) impractically slow. Partially homomorphic encryption just has to meet one of these criteria and can be much more efficient. An unintended, but well-known, malleability in the common RSA algorithm means that the multiplication of ciphertexts is equal to the multiplication of the original messages. So unpadded RSA is a partially homomorphic encryption system. RSA is beautiful in how simple it is. See wikipedia to see how to generate the public ( e , m ) and private keys ( d , m ). Given a message x it is encrypted with the public keys it to get the ciphertext C ( x ) with: C ( x ) = x e mod m To decrypt a ciphertext C ( x ) one applies the private key: m = C ( x ) d mod m The homomorphic prop