OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Public Comment

Comment from: dwheeler@dwheeler.com

Encryption - why this way?  Suggest alternatives.

The current specification includes an encryption method, but there seems to be no justification for using this particular one-off technique, nor is there a reference to a security analysis showing that this approach is okay.

If possible, this specification should re-use file encryption techniques used for similar problems, instead of trying to recreate everything.  Please don't re-invent the wheel!  An analysis should be referenced, and a way to support multiple encryption algorithms should be included.  More below.

I do not believe this approach is the "normal" way to encrypt zip files.  WinZip's approach is described at http://www.winzip.com/aes_info.html (using the AE-2 format), as released in January 2004, and I expect that to become quite common. I suspect the Info-ZIP folks will implement this approach as well. It does have a disadvantage that more than 160 bits of key aren't used (because it uses SHA-1 everywhere, instead of SHA-256 or SHA-195), but it'd be better to work with WinZIP and Info-ZIP to improve the encryption for everyone than try to have a unique encryption approach just for this situation.  This approach is similar to what you're already doing: you use a password to save, and the same password to retrieve.

Another approach would be treat zipped files as a binary blob, and then require any encryption be done via PGP.  Applications should be able to automatically open and decrypt, or save while encrypting, such files, if that's the approach.  That would support encyption and authentication, and there's an IETF RFC that you can appeal to as the standard (OpenPGP).

There are some XML-specific approaches.  However, since you ZIP files might include binary blobs for JPEGs, PNGs, etc., I haven't considered them further.

There's no explanation here about why a different approach is used.  If you MUST have a specialized one, at least explain why.  But consider that carefully -- better to NOT redo the wheel.  If the current wheels aren't good enough, see if you can get the wheel-makers to improve their wheels in general, instead of starting whole cloth.

The description given here doesn't seem to support multiple encryption algorithms.  One thing seems to be historically accurate: crypto algorithms generally get broken, sooner or later.  You need a format that can support several different encryption algorithms, so that people can choose more secure ones.  Indeed, it's wise to require that readers be able to read at least 2 decryption algorithms (pick 2 from, say, AES, Blowfish, and Triple-DES) so that, if an encryption algorithm is broken, everyone can quickly click on a configuration option and switch to using the "still secure" algorithm.  It beats trying to rush out implementations of everything that has to read a widely-used format.

Note that the current approach only support encryption, not authentication.  Many may want only authentication (digital signatures) WITHOUT encryption; describe the standard way that should be done (PGP signing?).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]