Skip to content
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

Closed
fdegros opened this issue Nov 22, 2022 · 4 comments
Closed

Make encrypted-but-not-compressed files seekable #336

fdegros opened this issue Nov 22, 2022 · 4 comments
Labels
enhancement Request a new feature. won't implement We won't implement this. If we receive usable patches, we will probably merge them.

Comments

@fdegros
Copy link

fdegros commented Nov 22, 2022

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 and zip_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.

@fdegros fdegros added the enhancement Request a new feature. label Nov 22, 2022
@dillof
Copy link
Member

dillof commented Nov 22, 2022

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.

@dillof dillof closed this as completed Nov 22, 2022
@fdegros
Copy link
Author

fdegros commented Oct 5, 2023

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.

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 $n$, you only need to know the encrypted blocks $n-1$ and $n$.

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?

@dillof
Copy link
Member

dillof commented Oct 6, 2023

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.

@dillof dillof reopened this Oct 6, 2023
@dillof dillof added the won't implement We won't implement this. If we receive usable patches, we will probably merge them. label Oct 6, 2023
@dillof
Copy link
Member

dillof commented Aug 21, 2024

No patches are forthcoming.

@dillof dillof closed this as completed Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Request a new feature. won't implement We won't implement this. If we receive usable patches, we will probably merge them.
Projects
None yet
Development

No branches or pull requests

2 participants