Why not start with encryption as provided out of the box by Java (6?). It's up to a user to install the string enc policy files or BouncyCastle or whatnot.
It's all plugable IIRC. Gary On Wed, Jun 12, 2013 at 4:04 PM, Siegfried Goeschl <sgoes...@gmx.at> wrote: > 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<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-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
