+1 and thank you, TJ, for fact-checking what actually happens. Folks, here is the issue.
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 .) -----Original Message----- From: TJ Frazier [mailto:[email protected]] Sent: Friday, March 23, 2012 11:26 To: [email protected] Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations On 3/23/2012 06:47, Andre Fischer wrote: > Hi, > > there has been a longer discussion about this in the issue ([1]), most > of it very technical. I previously thought that this is not a show > stopper but I changed my mind but more for usability than technical > reasons: I had expected that I could choose the encryption algorithm > either in the save dialog or in the Tools->Options menu, but did not > find a way to do it. Without this choice the user has two options: > > 1. Save as ODF 1.1 > > 2. Not use encryption > > > I don't find option 2 acceptable. Option 1 requires users to know that > this solves their problem, i.e. that ODF 1.1 uses another encryption > method than ODF 1.2. I did not know that before and assume that many > others do not either. > > I see this now as a severe problem, even as a show stopper. > > Regards, > Andre +1 I agree that this should be a show stopper, so that the patch from Dennis (or something to accomplish the same effect, and retain the current Blowfish method as the default) should be integrated. Given that, there are two more options to consider: 3. User change to config file, to use the new option. I have suggested a writeup on this, but such instructions are much better aimed at the (few?) users who want the "latest and greatest" security option, and will do a little work to get it. (Does anybody know what that file name is? Given that, I volunteer to update the Release Notes.) 4. Macro to toggle the settings. This could be distributed in a BASIC library (new or existing); no extension necessary. User instructions to find and run the macro are simple. I may be able to write this; preliminary investigation is promising but not certain. I volunteer to try. There are several real experts on this list, whom I might ask for help. /tj/ > > > > [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090 > > On 19.03.2012 14:48, Jürgen Schmidt wrote: >> On 3/19/12 2:16 PM, TJ Frazier wrote: >>> On 3/19/2012 08:48, Jürgen Schmidt wrote: >>>> Hi, >>>> >>>> I think issue 119090 is no show stopper from my point of view. The new >>>> default provides a better security than before when I understand it >>>> correct. And if people detect potential problems they can save the >>>> document again with other settings. >>>> >>>> I agree that this is important for interoperability but no show >>>> stopper. >>>> >>>> Any other opinion? >>>> >>>> Juergen >>>> >>>> >>> Hi, Jürgen, >>> >>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a >>> mention in the Release Notes; something like, >>> >>> PLEASE NOTE: the default options for [technical details here] should >>> provide your best /individual/ security. However, if you intend to share >>> the document in secure fashion, the default mode cannot be read by >>> * previous versions of OpenOffice.org >>> * current versions of LibreOffice, at least through [version] >>> * Ms Office [version info] >>> For compatibility, use the options [details here]. >>> >> >> I agree that it make sense to mention it in the release notes. >> >> Any volunteer for updating the release notes? >> >> Juergen > >
