Those regulations are why the default JCE policy is so restricted. I have to assume that there were a lot of lawyers involved in making sure that the Java approach to extending the JCE capabilities to more than 56/512 bits compiled with the law.
There encryption in two places in a zip file: the files and the central directory. The former could be easily handled via a plugin architecture, the latter would require much tighter integration but it's a fairly recent addition - you can provide file encryption without necessarily providing metadata encryption. As to the five extra fields themselves I don't have all of my notes with me but they are: 0x0014, 0x0019 - list of recipients as a collection of X.509 certificates in PKCS7 structure. 0x0015, 0x0016 - certificate ID + "signature data". I'm not sure yet what they mean by that. 0x0017 - identification of encryption algorithm, key length, processing flag (decrypt using password, certificate or both) You can't use certs for decryption, just authentication, so I don't know what their status would be. Strictly speaking all commons really needs is the ability to compare a certificate ID provided by the user with the certificate ID in the extra field to give a yes/no answer on whether to bother trying to decrypt the data or to just skip the entry. The keying material is kept in a "decryption header" preceding the compressed file data. See "Single Password Symmetric Encryption Method" section 3. It looks like it should be straight JCE with simple lookups - no dependency on anything other than the standard JCE API. Bear On Wed, Jun 12, 2013 at 2:09 PM, Gary Gregory <garydgreg...@gmail.com>wrote: > 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 >
