incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 119090] Default Encryption Fails for Down-Level Implementations
Date Mon, 19 Mar 2012 16:31:26 GMT

--- Comment #7 from orcmid <> 2012-03-19 16:31:26 UTC ---
Perhaps my report is not clear.  The current AOO 3.4 previews use AES256-cbc
encryption automatically.  Users are not given any choice.

No AES256-cbc encryption is handled by any distributions other than OOo-dev 3.4
(not a stable release) and recent releases in the LibreOffice 3.5.x line.  The
AES256-cbc encryption is not recognized and cannot be decrypted on earlier
releases of any OpenOffice-lineage distributions, including OOo 3.3.0,
LibreOffice through 3.4.3 (at least), and Lotus Symphony 3.0.1.  The failure is
reported with a misleading error message that suggests the documents styles.xml
is damaged, not that it can't be decrypted.

On the other hand, all known releases that support encryption will accept the
Blowfish CFB encryption exactly as they are produced for ODF 1.0, 1.1, and ODF
1.2 producers using default settings.

The recommended fix is to arrange that AOO 3.4 only use the ODF 1.0/1.1/1.2
default settings (and hence Blowfish CFB and SHA1 start-key-generation) in what
is produced automatically.  It is further recomended that it accept other
allowed encryptions (at least AES256-cbc) that are optionally usable when
opening encrypted documents.  Note that ODF 1.2 *requires* that Blowfish CFB be

Following the recommendation, AOO 3.4 would accept encryptions currently
produced by anyone and will produce the one encryption that *every*
encryption-supporting implementation accepts without problems.  It would also
correctly accept all encryptions produced by LO, whether using AES256-cbc or
something else on the optional list.  There is no user education required, and
there will be no support issues except by those seeking a way to use AES256-cbc
on purpose.  That can be handled in a subsequent AOO release when the smoke
clears on this problem.

If the release goes ahead using AES256-cbc, there will be a support nightmare
involving those people unable to unpgrade all of the installations where it is
intended that the encryption be decryptable.  In addition, where the decryption
fails, it will appear that AOO 3.4 has produced a corrupted document.  That
will not turn out well.

There is no reason to release something that causes known interoperability
breakdowns into the wild as the heralded first Apache OpenOffice release.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

View raw message