Default Encryption Fails for Down-Level Implementations

[Dennis E. Hamilton]

Here is a message that I have just sent to ooo-dev about the silent switching to AES256 being an interoperability problem.  The recommendation is to stay with the only cross ODF 1.0/1.1/1.2-conforming encryption of "Save with Password" by default, while accepting the newer optional ones (including AES256) on input.

The patch and bug report for LibreOffice 3.5.x is here: <https://bugs.freedesktop.org/show_bug.cgi?id=47484>.

If anyone thinks a license statement is needed from me to change two defaults from "sal_False" to "sal_True" I will be happy to provide it.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton at acm.org] 
Sent: Friday, March 23, 2012 13:24
To: 'ooo-dev at incubator.apache.org'
Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations

[ ... ]

The current builds of OOo-dev 3.4 (from Oracle) and all Apache OpenOffice 3.4 developer previews install with "Save with Password" pre-wired to encrypt using AES256-cbc and SHA256, and SHA256-1k digests, in conflict with the Blowfish CFB and SHA1, SHA1/1K digests that are all that down-level versions of OpenOffice-lineage and ODF 1.1 consumers can decrypt*d4e2h2*
, including Lotus Symphony, Libre Office prior to 3.5.x, and OpenOffice.or 3.3.0 (and earlier).

There is no dialog that notifies users that the encryption cannot be decrypted with earlier versions.  Changing the behavior requires knowing how to manipulate configuration settings.  There is no UI or Tools | Options dialog for this.

Fortunately, whichever default is used for Save with Password, both forms of encryption are accepted when opening a document.

THE PROPOSAL: Change the default so that the ODF 1.0/1.1/1.2-compatible and conformant encryption is used (Blowfish CFB and SHA1 for digests).  Users who want to produce documents using AE256, despite the loss of interoperability with all consumers but those who can accept AE256 -- LO 3.5.x, OO.o-dev 3.4, and AOO 3.4+ -- can still change their configuration files to alter the default behavior on ODF 1.2 Save with Password.

THE PATCH: There is a simple two-line patch to reverse the default behavior when there is no over-ride in the user configuration.  This is provided with r119090: <https://issues.apache.org/ooo/show_bug.cgi?id=119090>.  This patch needs to be approved and accepted.  (As a committer, I could have actually applied it.  I didn't want that done without review first, so this is an RTC submission.)

THE BENEFIT: Non-expert users will not be surprised by the misleading failure of their password to work when using a machine with an older version of OO-line software.  (The error message suggests that the file is damaged, not that the encryption is not understood.)  In addition, files that are encrypted using AES will also be decryptable by these new releases without the user having to figure anything out.

THE DEBATE: There is extensive technical discussion on the Bugzilla comments.  Here is a summary of what all of that technicality is about:

 1. Some presume that switching to AES256 increases the security of the document.

 2. The counter-argument is that it does no good to improve the security in parts of the encryption that do not improve the security of the weakest-link in the encryption technique.  It will simply give a false sense of security where there is no improvement.  The weak link in ODF 1.0/1.1/1.2 encryption is the way that passwords are used.  Not in the encryption technique that is used for the document.

All of the extensive technical material is about explaining how it is that (2) is the case and that doing (1) simply inconveniences users and raises technical and reputation issues. 

 - Dennis

PS: An equivalent patch has also been contributed to LibreOffice for remedying the fact that the change to AES has been instituted in LO 3.5.x .)

[ ... ]