-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make encrypted-but-not-compressed files seekable #336
Comments
Each block of encrypted data depends on the file data and previous block of encrypted data, therefore it is not possible to start decrypting in the middle of the file. Also, it's bad practice to encrypt a file without compressing it first, as it would make known plaintext attacks easier. |
This assertion needs to be nuanced. It actually depends on the encryption scheme. For example, if the encryption scheme uses a block cipher (eg AES) in CBC mode, it is possible to start decrypting in the middle of the file. To decrypt the block Could we check if the AES-based encryption schemes used in the ZIP format (AES-128, AES-192 and AES-256) allow for parallelization of the decryption? |
WinAES uses CTR mode, which supports random access. I don't know about PKWare. However, we probably won't get to implementing it, as it's a rather low priority edge case. We'd accept patches, though. |
No patches are forthcoming. |
Description
At the moment,
zip_fseek()
does not work if the file is compressed or encrypted (or both). While I understand why compressed files are not "seekable", I think it might be technically possible to get random access to an encrypted-only file (ie a file that is encrypted but not compressed). I would be interested in such a feature.Solution
If a file stored in a ZIP archive is encrypted without compression,
zip_file_is_seekable()
returns 1 andzip_fseek()
works.Describe alternatives you've considered
If an encrypted file is not seekable, I need to cache it somewhere else, which has performance, space and security implications.
Additional context
This is particularly interesting in the case of a nested ZIP where the inner ZIP provides the compression part and the outer ZIP provides the encryption part.
The text was updated successfully, but these errors were encountered: