libzip
libzip copied to clipboard
nih-at
Make encrypted-but-not-compressed files seekable
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.
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.
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?
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.