password protected Zip file #93
Comments
|
@mmguero Probably yes - it's especially a bit odd that the sibling package to this, https://github.com/uktrade/stream-unzip, can decrypt/open password protected ZIP files, but this package can't make them. Do you have a particular type of password protection that would be useful for your use case? There are a few: e.g. Legacy/ZipCrypto/Zip 2.0, or Winzip-style AES? (Or even, I think there's a more modern PKZip "official" password protected format that I don't know too much about, but I suspect creating such ZIPs might be a no-go without PKZip's permission) (Also: no particular ETA on this as well if you would like this for a current project) |
|
Yeah it's something of a tradeoff, isn't it? From what I understand the zipcrypto encryption is pretty easily cracked with brute force. Both WinZIP and 7zip (and a few others) support AES-256 which is much better security-wise but can't be opened by Windows natively. So it's a tradeoff of compatibility vs. security. Part of me almost says to go with the less secure, more compatible option because if I'm going to go with something they'd need to download 7zip for anyway I might as well just look at py7zr and create a .7z archive. But as a cybersecurity guy I also strongly see the argument for the real encryption. It looks like your stream-unzip package can handle both, so maybe making both an option? If not, I'd be happy with whatever you think would be best for the project's sake, I could live with either. |
I think I'm tempted for just Winzip's AES really. Keeps the API surface small, less scope for accidentally using the less secure one, less to code up, and since ZipCrypto is apparently so easy to crack, it would essentially just be adding code and faff without much of a benefit in terms of security - and maybe even a negative benefit if it's chosen rather than making sure both sides support AES. (I'm wondering now if stream-unzip should even remove support for ZipCrypto for a similar reason... hmmm....) |
|
I think that makes a lot of sense. AES is probably the way to go. |
|
Hey, So, for example, I don't need the best encryption but the ability to zip with a password as stream. |
|
@guysl10 That’s an interesting use case that I never considered… Essentially it’s to “work around antivirus”? What’s the antivirus? Is there no way to mark the specific file as allowed because you really want it? Also: what would then uncompress the compressed suspicious file? |
|
@michalc Yep, I want to help analysts download suspicious files from my website for investigations. I hope this explains my needs better :) |
|
Ah understood. Although one thing:
What would they use to uncompress it? And more specifically, would it support Winzip's AES ZIP format? |
|
@michalc The common use is to uncompress it to investigate the suspicious file (reverse engineering \ running in a sandbox). They should use standard zippers, Winrar / Winzip / 7zip, etc. |
|
@guysl10 Ah so it sounds like while AES is maybe overkill for your particular use case, it's still acceptable(?) |
|
@michalc Yes, you are right. AES could also work for me. But what is more important for me is the zip with the password than the level of encryption the zip will have. :) |
|
Just to communicate made a very small start on this in #94 |
|
#94 is getting there I think. Need to tidy it up a bit |
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
This adds AES-2 encryption as requested/discussed in #93 and defined at https://www.winzip.com/en/support/aes-encryption/ For now, AES-2 is used over AES-1 to prevent leakage of information via CRC-32 for small files, at the price of not having a checksum on the uncompressed plain text data (although there is an HMAC check on the encrypted compressed data as part of AES-2). In a later change, we should be able to make it AES-1 for larger files as recommended at https://www.winzip.com/en/support/aes-encryption/, but not doing this now to keep this change reasonably small.
…tion This changes documentation in what is now the "Password protection / encryption" section. It also changes tests to make sure the example in the documentation works, and to try to make sure that the examples in the tests are not seen as good practice. Specifically it links to https://crypto.stackexchange.com/a/109269/113464 which serves as a bit of a warning, but also contains some advice. And, it makes the password in the example longer and random. It does not implement all the recommendations at https://crypto.stackexchange.com/a/109269/113464 at least for now to keep this change small while I consider them - they may come in later changes (e.g. renaming password to passphrase or generating a default ourselves). This is done as part of the request/discussion at #93
…tion This changes documentation in what is now the "Password protection / encryption" section. It also changes tests to make sure the example in the documentation works, and makes the tests themselves use better practices, in case they are seen down the line as examples to follow in the real world. Specifically, it links to https://crypto.stackexchange.com/a/109269/113464 which serves as a bit of a warning, but also contains some advice. And, it makes the password in the example longer and random. It does not implement all the recommendations at https://crypto.stackexchange.com/a/109269/113464 at least for now to keep this change small while I consider them - they may come in later changes (e.g. renaming password to passphrase or generating a default ourselves). This is done as part of the request/discussion at #93
…tion This changes documentation in what is now the "Password protection / encryption" section. It also changes tests to make sure the example in the documentation works, and makes the tests themselves use better practices, in case they are seen down the line as examples to follow in the real world. Specifically, it links to https://crypto.stackexchange.com/a/109269/113464 which serves as a bit of a warning, but also contains some advice. And, it makes the password in the example longer and random. It does not implement all the recommendations at https://crypto.stackexchange.com/a/109269/113464 at least for now to keep this change small while I consider them - they may come in later changes (e.g. renaming password to passphrase or generating a default ourselves). This is done as part of the request/discussion at #93
Because the encryption has some gotchas and shouldn't be used if not informed, think it's more appropriate to be in the advanced section. This is done in response to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
This gives more specific limitations about AE-2, rather than just depending on external links. This is to allow people to make more informed decisions on whether to use it or not. I am maybe torn on whether to refer to AE-2's "flaws" or "limitations", but opting to use the word "flaws" since it's stronger and from the point of view of people's expectations of encryption, more accurate. This is done in repsonse to the request/discussion at #93
|
I'm going to now treat this as done. To summarise the changes... The related PRs: The main documentation change, which is now at: And release: If there are any problems, of course feel free to open an issue |
|
Hi @michalc , would it be feasible to also add legacy zipcrypto to this lib? (not used by default when requesting encryption but feasible with a boolean parameter for example) We propose downloading ZIP compressed files (executables that could be malwares) from our platform, and it's frequently consumed by python scripts (for instance to send to other platforms or sandboxes) which only support legacy crypto (stock python library only supports legacy ZIP crypto). Those scripts frequently go through HTTP proxies that perform AV scans so we need the files to be encrypted (even if slightly with bad/legacy crypto). Thanks in advance |
|
Understood the requirement, but I'm torn about adding it: we have no use for it ourselves, and it's pretty much the opposite direction of travel that I had in mind in terms of security (not that this any sort of policy or anything, just a rough idea in my head). What would your course of action be if we don't add it? Michal |
|
we are currently using a mix of pyzipper and zipencrypt to support both legacy ZIP crypto and AES one (with legacy for API usage and AES when accessing through a browser), and we're also hand crafting streaming tar.gz archives when not encrypting stuff this is kind of a historic mess and we'd very much like to rationalize everything and use a sole library (and switching from tar.gz to .zip file too) that meets all our features without removing already existing stuff (this would really annoy users that depends on the legacy zip crypto ecryption :( ) as we've recently stumbled on this particular issue (devthat/zipencrypt#2), this triggered a "we can do better and replace all this mess" process What would our course of action be? no idea right now, I completly understand that, in 2024, we should not implement weak crypto, but one of the main backend language out here (python) doesn't support "recent" stuff and we unfortunately need to accomodate this at work |
|
@mat-gas Several months later and I realise I never replied to you.
I think (maybe obviously by my lack of reply) I'm still not keen for this to go in. But also, looking at devthat/zipencrypt#2, at least in initial versions, it would probably hit a very similar performance issue since the encryption will probably use just pure Python.
The one thing I can point you to (apologies if you know) is that the sibling library to this one, https://github.com/uktrade/stream-unzip, supports the decryption of AES-encrypted files in Python. Not sure if this will fit into your setup, e.g. it wouldn't if you don't have control over everywhere the file goes to, but it crossed my mind that you could have stream-zip generating the ZIPs, and then stream-unzip reading them. |
Would it be possible for this library to support creation of a password-protected Zip file? I know there are some libraries like pyminizip that can do it but the streaming nature of stream-zip is much better in other respects.
The text was updated successfully, but these errors were encountered: