Default Encryption Fails for Down-Level Implementations

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@acm.org] 
Sent: Friday, March 23, 2012 13:24
To: 'ooo-dev@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 .)

[ ... ]