Move from OpenSSL to something faster for symmetric encryption

[smari]

The current use of openssl to do AES-256-GCM is kind of okay for now, but it is about 500x slower than using AES directly in (semi-)native code, mostly because of fork time.

Currently, a user with 5000 contacts will have to wait roughly 40 seconds from Mailpile launch until his contact list is working. Similar slowdowns occur elsewhere, for instance with the search index.

My vote goes to NaCl, of which some nice Python wrappers exist. In particular, this looks good: https://github.com/pyca/pynacl

[BjarniRunar]

Note that OpenSSL is also probably the most widely reviewed and best optimized encryption tool available to us.

I also wanted to point out that due to the Python GIL, forking an external process (especially if we can pre-fork the workers) is one of the simplest and most effective ways to leverage multiple processors on modern hardware.

For reading large volumes of small files (like the vcards) all at once, the overhead of forking will likely still dominate, but for less frequent reads and for larger data streams the trade-off will be reversed.

It is true that well written Python bindings will hopefully release the GIL, but that depends on the library and requires we do a lot more explicit threading in mailpile itself. However, crashes and security problems in said libraries will also bring down our whole app, which is why the trend in things like browsers has been to move towards multiprocess architectures, not away from them.

[public]

@BjarniRunar We're working on https://github.com/pyca/cryptography which provides (GIL releasing and PyPy compatible) OpenSSL low level bindings and higher level crypto APIs. If there's any particular features you'd think would be useful please let us know :) We've not got our asymmetric API sorted out yet but hashes and symmetric stuff are working well.

You make a good point about multi-processes providing some useful isolation. You'd get that pretty easily via multiprocessing though?

[pagekite]

Thanks for the pointer! We'll take a look when we are closer to doing something about this issue.

[BjarniRunar]

Relates to #1228

[BjarniRunar]

Pull request #1684 starts the move from openssl to pycrypto.

It's not faster (yet), due to massive Python overhead it's slower. Sorry! Fixing this requires changing the container format, which is also in the works but will take longer.

The slowness of @smari 's contacts is honestly probably more due to the slowness of our VCard parser than it is due to openssl. Again, fixing this requires reorganizing how we load and store data.