On 2013-06-12, Bear Giles wrote: > What is the status on strong encryption in zip files? That is - I know we > don't have it, but is there a reason why it hasn't been added or is it just > an itch that hasn't been scratched?
> I can see several levels of values > 1. add ZipExtraField handlers for the five extra fields of interest (0x14, > 0x15, 0x16, 0x17, 0x19) even if encryption/decryption isn't supported. It > could still provide useful information, e.g., identifying users able to > decrypt the file. > 2. add read-only support. > 3. add write support. > The two potential issues I've found so far are 1) export/import > restrictions that may limit functionality and 2) language in the PKWARE > documentation at http://www.pkware.com/documents/casestudies/APPNOTE.TXT. export/import restrictions are no big problem since we'd basically rely on JCE anyway - we might need to add Compress to <http://www.apache.org/licenses/exports/> but nothing more. For me the note from APPNOTE.TXT is the major problem, but then again we've never consulted with our legal folks or reached out to PKWARE to see what is and what is not possible. The first item of your list - adding extra fields - should still be possible. > A related question involves support for the legacy encryption. It's > easily cracked but people might need to read old encrypted files. It's > even possible that some people may still be forced to use it because > of contractual obligations. Read-only support would probably be nice, write support is something I personally wouldn't be interested in - as it provides some false idea of privacy. TBH two years (or more?) ago I flagged all JIRA tickets related to alternative compressions methods and encryption as 2.x as I expected us to come up with a proper API for this first - obviously nobody has found the time or need to work on the 2.x API so far. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
