Skip to content

HBP-95: Enable Upload of Encrypted data files in TVB Web GUI

Marmaduke Woodman requested to merge HBP-95 into master

Created by: VinczeRobert

It's not quite complete, but I thought I'll push what I have so far because as we discussed with Lia today, it got a little more complicated than we expected.

The first thing to note is that the script I wrote treats each file in the same way, so for example we won't unzip a zip and encrypt each file separately,but the whole zip itself.

The decryption is not done yet, because I don't really know what would be the best way to do it in terms of how much we modify the existing code in uploaders. As a result of the previous paragraph, for example, in ZipConnectivityImporter currently the path to the chosen zip is sent to be unzipped, but now we would need to first decrypt the zip file, save it somewhere temporarily, and send that to the unzip function. And we should do this only if we take the file as encrypted i.e. if the user specified the encrypted AES key.

As for why we need both asymmetric and AES encryption (which is symmetric), I think my comment on the task and especially the links added should be pretty good explanations: https://req.thevirtualbrain.org/browse/HBP-95.

Besides any other ideas for improvement that there might exist, I would have three questions:

  1. Related to the 3rd paragraph here. The way the code is now, we must a) Decrypt the zip file. b) Save the decrypted zip file. c) Send it to FilesHelper.

Couldn't we do something so that we skip step B or is it not a problem if we save it?

  1. I understood that there will be one public key and one private key which will be constant (currently a new pair generates at each launch, the public key can be downloaded by the user and the private key is kept in session). I also understood that the public key will be available on the website, but where do we keep the private key?

  2. In the crypting.py script I wrote, on line 26, there is a parameter modes.CTR(iv). That iv is supposed to be generated randomly and it is supposed to be different at each encryption, I left it a constant now so I can make this PR. I will probably research it a little bit more to see what it does exactly, but it is probably a part of the AES encryption/decryption algorithms. My idea would be to somehow include that parameter in the same .pem file as the encrypted key, but that would complicate the encryption for the user even more. Or we could just leave it a constant. The reason why it shouldn't be a constant is that it is not secure enough, but we don't use AES alone, we use it in combination for RSA, so maybe we could live with that. Any ideas here?

Merge request reports