Enable recipients to export the submission with an AES encrypted zip file

[evilaliv3]

As an improvement for #931 it would be valuable if recipients could download the file with an encrypted zip file.

[evilaliv3]

@fpietrosanti: following the research performed with the clientside crypto few are the things to be kept into account that would make this desiderata difficult; the main critical aspect is that we will have to perform zip+aes clientside.

The interesting aspect if one day will be able to do this is that we can make the user use the same password of the platform or eventually create an independent one but still stored encrypted on the server with the same mechanism of the end2end encryption so that the client will be able to use the password in a transparent way to the user to create the zip files.

The only big concern in being able to do this is that none of the current javascript libraries have such a support.

Im currently considered:

• https://github.com/gildas-lormeau/zip.js (https://github.com/gildas-lormeau/zip.js/issues/13)
• https://github.com/antelle/node-stream-zip

[evilaliv3]

Related:

• https://github.com/Stuk/jszip/issues/8
• https://github.com/Stuk/jszip/pull/129

[NSkelsey]

@evilaliv3 is the idea of implementing streaming in openPGP-stream still on the table?

Is streaming an encrypted zip file the use-case for the OpenPGP-js issue. If not could you point me to the issue in GL.

[evilaliv3]

The implementation of the stream is working, but i would now suggest that we consider first to implement it in a non streaming way and then to overcome the possible limits with that.

I answer here your doubts but then let's eventually discuss in relevant tickets:

• the need for streaming is to avoid to use too much RAM but sadly all the research we did will allow to work in streaming only during upload, but in the end for the download the user will have still to decrypt/save the file as a whole; anyhow i found that in the future it would be great anyhow to have the file upload in streaming because i think that it will allow the whistleblower to use a limited hardware while we can expect the recipient to have more resources.
• the zip for the upload has never been considered by any ticket but every file is uploaded indipendently and this make possible to start uploading as soon that the user add files (and anyhow the browser will use gzip while uploading)
• the zip (by this ticket) is considered only for giving to serve to the recipient a zip encrypted with AES but i putted the issue in the Whishlist as it is by now unfeasible as 1) there is no library that clientside allows to create AES zipfiles 2) we should concentrate on other topics that need completion.

[evilaliv3]

I consider that we could restart working on this ticket that considering that files are now downloaded unencrypted would provide important guarantees to the export of the submissions.

I consider in fact that offering an easy possibility to users to export submissions encrypted in a an AES-256 encrypted zip file could be a nice feature.

A secure password could be clientside generated and eventually shown to users on the screen.

[evilaliv3]

@danifus: I'm looking at your nice implementation of https://github.com/danifus/pyzipper considering to replicate your schema on our version of zipstream: https://github.com/globaleaks/GlobaLeaks/blob/main/backend/globaleaks/utils/zipstream.py

Do you consider that you implementation would easily map on it and would be able to fully work in streaming?

(p.s.: Within globaleaks we could only use software libraries that are included in Debian/Ubuntu as package so that we won't be able for the moment to just use directly your library but in case i will reuse any of your code i will take care to add a mention. Thank you)

[danifus]

Hi,

Both implementations were derived from zipfile.py at some point so there are a lot of similarities. Having a quick look at zipstream, I think it would be be pretty straight forward to integrate. Keep in mind that winzip's AES encryption (which pyzipper implements) doesn't encrypt the filenames. Let me know if you run into any problems integrating it.

Cheers, Dan

[evilaliv3]

Thank you @danifus for your feedback.

I've two questions actually:

• Up to your knowledge this kind of winzip files is nowadays natively supported on every operating system? if not, is there any free and open source software available that could be used on any operation system to open them?
• is there any good alternative that you would suggest in order to have filenames encrypted as well ?

[danifus]

The ability to decrypt the winzip files is not natively supported by any OS as far as I can tell. 7zip is an open source tool that I recommend for handling these files. It is available for windows, mac and linux. There is also Winzip but it requires a purchase and there are probably other programs that can handle these files too.

I haven't looked into encrypting the filenames. I primarily wrote pyzipper because I was receiving files with the winzip AES encryption. 7zip has a few additional encryption methods. One of those may do that but I haven't checked.

[elbill]

I also believe this is a useful feature. So far I instruct users to decompress and compress with 7zip when they need to send encrypted report exports, which involves a few steps in their workflow and sometimes they may not comply and may send unencrypted files over email or non secure channels.