Tunnel crypto improvement with AESGCM

[Captain-Coder]

I had a look at why my tunnels are slow. Without having run a profiler, my fist guess was the crypto layer. So I did some poking around in tunnelcrypto.py. And saw it creates a lot of python objects just to do one encryption run. So I peeked at the docs for modes.GCM, it contains a hint to use AESGCM when doing small batches of data. So does this pay off?

import timeit
timeit.timeit('cipher = Cipher(algorithms.AES(key), modes.GCM(initialization_vector=nonce), backend=default_backend()).encryptor()\ncipher.update(data) + cipher.finalize()', setup='import os\nfrom cryptography.hazmat.backends import default_backend\nfrom cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes\nfrom cryptography.hazmat.primitives.ciphers.aead import AESGCM\nnonce = os.urandom(12)\nkey=AESGCM.generate_key(bit_length=128)\ndata=os.urandom(396)')

38.672110080718994

This would be our current tunnel crypto code. But when using AESGCM:

timeit.timeit('aesgcm.encrypt(nonce, data, None)', setup='import os\nfrom cryptography.hazmat.primitives.ciphers.aead import AESGCM\naesgcm = AESGCM(AESGCM.generate_key(bit_length=128))\nnonce = os.urandom(12)\ndata=os.urandom(396)')

18.620353937149048

So nearly a 2x speedup there. But I don't know if i did this right (read: securely), and it is a breaking change. AESGCM includes it's own tag, whereas the current tunnelcrypto.py has to .pack() it along with the data (so the savings might even be better). So perhaps someone can investigate this for the future.

[devos50]

@Captain-Coder interesting, thanks! :)

[synctext]

Thnx, this breaking change should land in 7.3 nicely. Anything for double speed!

[synctext]

Reminder: thesis-grade material! !

[ichorid]

@egbertbouman , don't you mind lookin' at this one? Should we put in on 7.4?

[egbertbouman]

@ichorid It's already implemented (Tribler/py-ipv8@ea90aad),