Support AES encryption in FastZip.CreateZip

[Numpsy]

Provide a means of enabling AES encryption when creating zips with FastZip (by settings the AESKeySize of the entries it creates prior to giving them to ZipOutputStream).

Notes:

• I added a new mode enum in its own file rather than in FastZip.cs (easy to merge if needed).
• I'm not sure if the encryption mode should have a 'None' option, given that the setting only applies if the password property has been set seperately?
• The call to TestArchive in the unit tests is commented out because of ZipFile.TestArchive seems to always return false for AES encrypted zips #317

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

[Numpsy]

A question about naming on the encryption mode enum:

If ZipFile gets support for adding AES encrypted entries to archives then it will need some means of specifying the encryption method to use, which might mean a new property on ZipFile.
If it had such a property, the type could be the same as for FastZip, or it could be different, not sure which is best (two enums vs. the possibility that they might end up different at some point).

Basically: Is 'FastZipEncryptionMethod' a reasonable name, or would something more shareable be better?

[piksel]

Hm, why would they ever need to be different? They are both working with the same spec., do you mean support-wise?

[Numpsy]

Yes, support wise (though spec changes aside I don't think that would happen outside of someone implementing that PKWare strong encryption method in one and not the other, which seems unlikely in general)

[piksel]

I would probably go for using a common Enum.

[Numpsy]

ok

[Numpsy]

Thinking about my second question ("should there be 'None' encryption option") - If you were using the same enum for ZipFile then you might possibly want to be able to open a file that contains encrypted entries and add new ones which are unencrypted, which might not work if you're just basing the application of encryption on whether a password has been provided? (hence a non-option being useful).

Not sure what the best api change for ZipFile is though

[Numpsy]

With regards to my suggestion in #454 about creating a custom entry factory that sets the AES key size properties:

This change has a possible conflict with that, in that if you set FastZip to use ZipCrypto encryption (the default), and then set the AES key size to something non-zero in the entry factory, then FastZip would overwrite that with it's own value, Not sure how much that counts as a problem? (The way ZipOutputStream works just off the key size, and that being an int that defaults to 0, means that you can't really just put the entry factory in charge as you'd end up overriding the FastZip option with ZipCrypto in the general case.)

You could maybe make ConfigureEntryEncryption just upgrade the encryption strength or some such, but then you might just say that FastZip is for simple use cases, and this is a non-issue.

[piksel]

Couldn't FastZip be modified to look at the AES key size, and not modify it if it's non-zero? Or am I missing the problem here?

[Numpsy]

yes (it's just something where it needs a descision on how it should work.)

[Numpsy]

updated

[piksel]

I think this looks good. Does this fully enable AES encryption for FastZip, or is something else needed?

[Numpsy]

I think this looks good. Does this fully enable AES encryption for FastZip, or is something else needed?

I think that might be it as far as FastZip is concerned, as all the actual work is done in ZipOutputStream, though it might need #460 being completed first to avoid it creating bad entries for folders.