client-zip
client-zip copied to clipboard
Touffy
[FEATURE] Encryption
Why is your feature relevant to client-zip?
Encryption is on client-zip roadmap, but the author does not see use case for it. Therefore, I would like to add my use case.
Describe the solution you'd like
I am running workers to backup data from cloud services to another, as zip archives. Certain users have requested for their backups to be encrypted, since they may contain personal data. Currently, I have to fetch data locally, zip it with encryption, and then upload again. It would be nice to be able to use client-zip to do it all in one step.
Describe alternatives you've considered There is not really a JS library that does encryption for zip, so the alternative is really just to download data all at once, zip it with encryption, and upload the result.
Like I said, the feature should be easy to implement with WebCrypto. Thank you for bringing this use-case. It is a little unusual : typically, you would decrypt the data in the same layer where you encrypted it.
So if I get it right, you have access to unencrypted user data ; your plan is to let the users input a password or a key, zip their files into an encrypted archive, and then later allow them to download the encrypted archive and decrypt it with their own Zip program ?
So if I get it right, you have access to unencrypted user data ; your plan is to let the users input a password or a key, zip their files into an encrypted archive, and then later allow them to download the encrypted archive and decrypt it with their own Zip program ?
That's correct! Our backup solution is long term, like database dump for example. When the user needs the backup, they need to download it and extract using their key.
There are two options that I could implement mostly with WebCrypto primitives. In both cases, an AES key is used internally to encrypt the actual data. The key will either be randomly generated and wrapped with RSA, or derived from a password.
With RSA, the user must provide only the public key for encryption. It's pretty secure, but obviously the user has to know how to create an RSA key pair on their computer, and keep it safe.
The password-derived option is more accessible, but has the same drawbacks as other password-based systems (fishing, keyloggers, interception when one user shares the password with another over an insecure channel or writes it down on a post-it or reuses compromised passwords…).
Anyway, you should know that the Zip format is not exactly state-of-the-art when it comes to encryption. It may be convenient and somewhat standard, and it will protect data from casual inspection. But if your users are worried about skilled and motivated attackers, you might want to rethink this whole encrypted Zip idea (especially with password derivation).
I think basic encryption is fine. They are currently fine without encryption :), so the extra protection layer is a peace of mind to have. I agree that many users won't know how to use RSA keys.
Keep in mind that this "peace of mind" means the data will be lost "permanently" if the user loses the password.
I use quotes around "permanently" because Zip password derivation can be brute-forced nowadays, given some time, the right tools, and a few assumptions about the password.
After studying the spec and searching the Web in vain, I am officially dropping RSA public key encryption. Just in case someone else comes along wanting that feature : sorry, won't do. I won't even accept a pull request to add it to client-zip if someone manages to implement it. If your users are advanced enough to use public keys, I suggest you let them encrypt the whole file with PGP instead.
Why not RSA ? I couldn't find a single open-source implementation, and it's based on an old Microsoft key format. More importantly, there is practically no zip utility that supports RSA (except the original PKWare Zip program), so even if client-zip could use this encryption, most users would be left unable to ever decrypt the result.
Password-based encryption is still on the table. It's horribly complicated of course, but it seems to be all there in the spec, and decryption is supported by most programs. I still wouldn't recommend it because of all the inherent vulnerabilities of passwords, but I'll do it.
Anyway, "strong" encryption (that is, encryption that can't be broken in a matter of minutes and doesn't leak all your metadata) requires the Zip64 format, so this feature will be exclusive to the 2.x branch (and future branches) of client-zip.
Sorry, I haven't taken the time to write it yet (kinda annoyed at how incredibly complicated the Zip designers made that feature…). You need it too ?
Well, password protected zips would be huge. We have a whistleblowing portal, which uses web crypto for clientside e2ee. And looking into generating zips clientside for export.
Very cool. You'll have to generate a strong random password that the user will need to safely store somehow. The password is usually the weakest part of a system with AES encryption, especially with the old SHA-1 key derivation in the Zip format.
Anyway… thanks for sharing your use-case. I can't promise anything, but I may take a shot at it in September.
Yeah we already have a mix of AES-GCM, RSA-OAEP and PBKDF2. The basic use case for us is to enable the user to export reports and attachments in a single zip for convenience. And in the end we just want to make sure that there is a way to get stuff out of the system and still be at least a bit secured.
If you have a branch open feel free to share it, need to read up the zip spec but might contribute a bit.
I haven't started a branch yet.
Have fun with the spec ! It's mostly in section 7.2 and following of the Zip APPNOTE, though there are bits spread out all over the place.
After some further reading and puzzling, I discovered that PKWARE's spec (the "APPNOTE") does not fully specify how to implement the "strong" AES encryption. In particular, they do not explain the key derivation function.
What every other Zip utility implement when doing encryption is either the ancient "not strong at all" method, or a third-party AES method invented by WinZip and specified here. Thankfully it is much simpler than PKWARE's method, although it does leave more metadata in the open.
To be very clear : only the file's checksum is hidden, but you can see its name, exact length, and modification date. That sucks, compared to the encryption method described in section 7 of the APPNOTE, which hides all of those.
Knowing this (and knowing that there isn't really a choice, because nobody except the proprietary PKWARE app supports section 7), is it really useful for your use-case to encrypt only the file contents, no matter how strongly ? Filenames, dates and lengths would probably be damning evidence against a whisleblower even without the contents, should such a file end up in the wrong hands.
I urge you to reconsider relying on the Zip format for encryption. PGP can provide password-based encryption — not just RSA — and is easy to install for free on any OS (in the form of GPG) and it can be applied to any file format in case you want to replace the Zip stage with something else. Alternatively, 7Zip is rather well-known, available for free on all platforms and has decent password-based encryption.
Due to the severe limitations explained above, I have decided to close this issue as "won't fix". There will be no encryption support in client-zip because it would suck no matter what.