Please see <https://issues.apache.org/ooo/show_bug.cgi?id=121141> in addressing security vs protection in the UX also.
1. CHOICE OF ENCRYPTION ALGORITHM It is important to appreciate that there is no recommendation about AES for the ODF 1.2 manifest:algorithm-name. The only mandated algorithm for conformant ODF 1.2 documents, producers, and consumers is Blowfish CFB. Other encryptions defined in XML Encryption 1.0 are allowed in conforming documents but there is no interoperability provision for them in ODF 1.2. The choice for Save with Password should be simply whether to use ODF 1.0/1.1/1.2 Blowfish or (for ODF 1.2 only) AES-256. 2. HASHING THE START KEY The only place where there is a meaningful SHA1 versus SHA256 determination for encryption is in the choice of manifest:start-key-generation-name. This choice is independent of the encryption used. It determines whether a 160-bit or a 256-bit password hash is provided to the PBKDF2 with HMAC-SHA-1 for derivation of the actual encryption keys to be used. That hash is a secret and there is some improvement in protecting the encryption when SHA256 is used. For ODF 1.0/1.1/1.2 across the board, the common provision is with SHA1 as the default. The use of SHA256 and provision of the optional manifest:start-key-generation-name attribute applies only to ODF 1.2 documents. IMPORTANT NOTE: When selecting 256 for ODF 1.2 encryptions (preferably only with the use of AES in ODF 1.2 documents), the URI <http://www.w3.org/2000/09/xmldsig#sha256> in the ODF 1.2 specification is INCORRECT. It should be <http://www.w3.org/2001/04/xmlenc#sha256>. See <https://tools.oasis-open.org/issues/browse/OFFICE-3795>. If it is thought meaningful to feed an SHA256 into PDBKDF2 instead of starting with an SHA1, by all means use it for ODF 1.2 documents when AES is the encryption algorithm. There is probably no reason to make this an user-selectable option since ODF 1.2 consumers must accept either case and it is unclear what informed choice is to be expected of users. 2. OTHER HASH CHOICES DON'T MATTER MUCH FOR ENCRYPTION There should be no user selection concerning SHA1 versus SHA256 with respect to manifest:checksum. The manifest:checksum and manifest:checksum-type provisions are neither security nor privacy related. They are to assist in checking whether the decryption is succeeding. The mandated cases for consumers only work on the first 1k bytes of the unencrypted file part and the choice between SHA1-1k and SHA256-1k is insignificant. Only the SHA1-1k will work across all of ODF 1.0/1.1/1.2. SHA256-1k must be supported by ODF 1.2 consumers, so it is safe to use when producing an ODF 1.2-specific AES-256 encryption if desired. In this particular application of digital hashes, there is however no advantage of SHA256 over SHA1 and faster is better. Note: Either way, these checksum values disclose information about the *unencrypted* package file. In the future, it is desirable to use encryption algorithms that allow manifest:checksum to be dropped while also verifying the integrity of the encryption/decryption. 3. SELECTING HASHES FOR PROTECTION Making a choice between SHA1 and SHA256 for *protections*, not encryptions, is meaningful only when a document is saved as ODF 1.2. There is no choice when saving as ODF 1.0/1.1/1.2 for legacy compatibility. The across-the-board default is SHA1. Since protections are trivially defeated without any concern for the digital hash value of the protection key, the only reason for SHA256 is to make it slightly harder for someone to discover the password from the protection key. Since the protection key value is not a secret and it is easily extracted from the document, SHA256 versus (160-bit) SHA1 is not a big improvement. Passwords used for protection keys are vulnerable to compromise and exploitation. See <https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html>. - Dennis -----Original Message----- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Friday, December 07, 2012 08:39 To: dev@openoffice.apache.org Subject: [UX] UI options for document encryption On Fri, Dec 07, 2012 at 05:19:11PM +0100, Jürgen Schmidt wrote: > >> The "Encryption GUI" item has not attracted a sponsor. I added > >> this per the resolution of a very long discussion in BZ [1]. > >> Subsequently, Jürgen wrote an extension to set "SHA256" mode, and > >> I wrote a macro[2] to toggle the settings; both are still > >> available. (I have no idea whether any or many users have used > >> them.) > >> > >> [1] <https://issues.apache.org/ooo/show_bug.cgi?id=119090#c31> > >> > >> [2] <http://wiki.openoffice.org/wiki/User:TJFrazier/Encryption> > >> (this page includes text suitable for release notes) > >> > >> If somebody wants to pick up on this, and implement a GUI > >> (probably in Tools > Options, possibly on the Save and Save As > >> dialogs), that's wonderful. Lacking all fu for SVN and C++, I > >> can't volunteer for this. > > > > the best way is to start a new thread asking for UX advice where > > to include the option. IMHO the Save dialogs are a no-go, the > > average user will have no idea what this means. > > > > On the other hand, Tools > Options > Load/Save > General has almost > > no space to add anything else, but may be a new "Encryption" > > options page is an overhead... > > > > Mmh, maybe directly over the "Size optimization ..." checkbox. > > I have thought initially about Tools -> Options -> OpenOffice.org -> > Security. There should be enough place for a checkbox with some > explanation. Changing the subject so that Kevin et al. can find it. Regards -- Ariel Constenla-Haile La Plata, Argentina
