ZipZap
ZipZap copied to clipboard
pixelglow
Does zipzap support password encryption?
My project needs the ability to delete/replace a file entry in an zip archive, but also need to support password. Does zipzap support password? If not, is it on the road map to support in a near future?
I currently have no plans to add password encryption, but the library should be flexible enough to add the "traditional" zip-based encryption. If you or anyone wants to attempt this, I'll certainly review the pull request. Alternatively, you can contact me at glen low at pixelglow dot com if you're willing to contract me for this.
As for the strong encryption option, it appears to be covered by some PKWARE patents, requires an additional license and may not be appropriate for an open-source project.
See the zip file format specification for more details.
We have a working password decryption in place, thanks to @Danielgindi, see #49.
Update - AES is in a pull request. Encryptions should be relatively easy to implement now, using the same core functions (just in the other direction).
Any update on encryption? I figured out why I was having that file that wasn't encrypted :-)
And also... In ZZAESDecryptInputStream.mm I see this method call:
CCCryptorCreate(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionECBMode,
derivedKey,
keyLength,
NULL,
&_aes);
Shouldn't the first parameter be: kCCDecrypt? Because you are decrypting those files. That's what I understand from a quick look over the CommonCryptor.h file.
No, I guess that is why it did not work for us earlier, we tried with kCCDecrypt. AES is symmetric, and the algorithm that CC runs on kCCDecrypt does not suit the method that WinZip takes.
On Wed, Feb 12, 2014 at 6:27 PM, cyupa [email protected] wrote:
And also... In ZZAESDecryptInputStream.mm I see this method call:
CCCryptorCreate(kCCEncrypt, kCCAlgorithmAES, kCCOptionECBMode, derivedKey, keyLength, NULL, &_aes);
Shouldn't the first parameter be: kCCDecrypt? Because you are decrypting those files. That's what I understand from a quick look over the CommonCryptor.h file.
— Reply to this email directly or view it on GitHubhttps://github.com/pixelglow/zipzap/issues/26#issuecomment-34885973 .
I'll also have a look on it and see what I can do about it. Sadly, my knowledge on zip files and their file headers is near to none.
If I understand you correctly, what you are missing really is encryption instead of decryption? I might implement that soon
On Wed, Feb 12, 2014 at 6:51 PM, cyupa [email protected] wrote:
I'll also have a look on it and see what I can do about it. Sadly, my knowledge on zip files and their file headers is near to none.
— Reply to this email directly or view it on GitHubhttps://github.com/pixelglow/zipzap/issues/26#issuecomment-34888813 .
Yes. The decryption works ok, and indeed it seems that it works with kCCEncrypt instead of kCCDecrypt. The file I uploaded yesterday (if I remember correctly) was created with zipzap. But I somehow overlooked the fact that there was no ZZAESEncryptionOutputStream and no encryption.
Because I need that, I'm willing to look into it, as far as I can go, and try to implement it.
@cyupa, @danielgindi -- I would definitely appreciate an encryption implementation! Do note we probably have to refactor the stream classes for encryption in the same style as the ones we did for decryption.
As for using kCCEncrypt in the CCCryptorCreate call, this is because we're implementing the CTR mode, which is a two-step process. The first step is to create a keystream by encrypting sequential numbers. The second step is to XOR this keystream with the ciphertext to produce the plaintext (decryption) or vice versa (encryption).
Any word on creating password protected zip files? (I have no knowledge of programming in this area or I would readily contribute)
