Hi folks,
don't know if this was already mentioned but providing strong encryption
causes administrative head-ache
http://www.apache.org/dev/crypto.html
Cheers,
Siegfried Goeschl
On 12.06.13 16:29, Bear Giles wrote:
This morning I realized that the license requirement could be a real
problem if it applies to the end developer instead of or in addition to any
libraries. On the other hand it might just be a completely reasonable
requirement that the code be tested for compatibility with PKWARE and the
license requirement would stop with the library. I have no idea.
Fortunately I think it would be easy to design this around a injected
interface, something like
byte[] encrypt(byte[] plaintext, List<ZipExtraField> fields)
and likewise for decryption. The fields are immutable for decryption but
not encryption. (It looks like streaming isn't always possible since the
headers contain checksum information but I need to re-check that.) This
could be generalized to allow arbitrary transformations - compression,
encryption, etc., albeit at the loss of interoperability if developers
create their own. In this case the encryption could be provided in a
separate library.
On the encryption itself I can understand the concerns about the false
sense of security with the legacy encryption but the newer stuff looks
strong - it supports AES, has a unique encryption key for each file,
prepends randomized data to block known plaintext attacks, etc. You can
encrypt the metadata (filenames, etc.) I definitely think embedded
encryption is better than running it through PGP since a damaged file is
much more recoverable - just scan through the file for the next
(unencrypted) header. PGP also chunks data but there's no correlation
between the PGP chunks and the zip entries.
A clean room implementation based on the APPNOTE is looking like it might
be a challenge. It's a good overview but it doesn't document key things
like how the per-file session key is generated from the master key. I don't
know how much I can peek into other open-source implementations without
running afoul of "original work" requirements - obviously I would never
cut-and-paste but some of this has only one possible implementation modulo
window-dressing. (E.g., how do you call the method?) Maybe that's provided
as part of a developer pack after you contact them about a license.
Bear
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
