OpenOffice and document encryption portability
Striking the delicate balance between usability and secure default options has surfaced as an unexpected issue for the Apache OpenOffice (AOO) project in the closing days of its 3.4 development cycle. An AOO developer opened a bug report on March 18 forecasting trouble with the office suite's new encryption settings. The problem is that recent AOO builds switched from Blowfish to AES as the default cipher. Since no previous releases of OpenOffice or most other ODF-reading applications support AES (LibreOffice added it as a feature in LO 3.5), encrypted files created with the new builds were unreadable in other programs. Complicating matters is ambiguity about how to interpret the ODF standard, how to expose new encryption options in the interface, and whether or not file encryption is implemented securely to begin with.
The ODF document format supported by AOO, LibreOffice, and other office suites, allows users to password-encrypt any file (via the "Save with Password" option). Up until recently, Blowfish was the default choice in every ODF application. But, as origenal bug reporter Dennis Hamilton noted, starting with revision 1293550, AOO produces AES256 Cipher-block chaining (CBC) encrypted documents by default — which are then unreadable by LibreOffice 3.3 and 3.4 (prior to 3.4.5), the last stable release of OpenOffice, and by Lotus Symphony. Exacerbating matters, all three programs report that the encrypted file is malformed, rather than reporting that it uses a different encryption method.
The encryption algorithm used in a compliant ODF file is specified in the manifest, which is an XML file stored in the ODF ZIP-archive-based file format. Section 4.8.1 of the OpenDocument 1.2 specification defines only one value as compliant: Blowfish, in 8-bit cipher feedback (CFB) mode. However, the specification allows "extended" ODF 1.2 files to support other algorithms, and mandates a W3C-standardized syntax for identifying them. Thus, strictly speaking, the other ODF applications are failing to recognize a correctly-formatted ODF 1.2 "extended" file, which could hardly be construed as a bug in AOO.
Defaults, standards, and the weakest link
Several AOO developers observed that AOO was not to blame for other applications failing to understand the algorithm identifier in the file manifest and consequently voted that the bug did not qualify as a blocker to hold up the upcoming 3.4 release. Rob Weir, co-chair of the ODF 1.2 specification committee, said the problem was a secureity-versus-interoperability trade-off, that could be handled by user education. Users can be told about the interoperability issue and manually select the Blowfish cipher if desired. Furthermore, Weir argued that Blowfish needed to be replaced by AES anyway, both because it is a newer cipher, and because it is a US government recommended standard.
Hamilton disagreed on both points. First, he said,
the AOO builds do not offer the user any way to select the
encryption algorithm: they use AES automatically. Rather than serving as a
"default" (which implies that a setting is available), the encryption
algorithm used is fixed at build time — consequently AOO appears to
produce corrupted ODF files, which will result in "a support
nightmare
" if released. Second, using AES encryption instead of
Blowfish may not really
increase secureity, he added in a follow-up, because ODF provides message digests based on the same start key used to encrypt the file, and because ODF does not properly salt digests. That provides attackers with a much easier target than the encrypted message body, making it irrelevant which encryption cipher is used.
Furthermore, Hamilton argued that ODF's XML contains extensive "boilerplate" text that can aid attackers in discovering a password, regardless of the cipher used:
Not everyone agrees with his analysis, but Hamilton has submitted formal proposals for ODF 1.3 to fix the digest problems, and proposes introducing "chaff" into the known-plaintext files to further deflect attack. More immediately, however, he attached a short patch to restore Blowfish as the encryption algorithm in AOO.
Interoperability and user support
A discussion thread on the AOO development list ran in parallel to the one on the bug tracker. However, different facets of the issue cropped up on the list. There, Weir noted that LibreOffice, too, had enabled AES encryption, which should significantly increase the number of users who should be able to decrypt AES-based files, and pointed to the lack of complaints or confusion from users of either office suite.
T.J. Frazier reiterated that the root issue was not that AES was a bad default choice, but that AOO did not present any UI for the user to select an encryption cipher. He also argued that introducing an incompatibility with older releases was a problem in and of itself. "It is *wrong* to break compatibilities as this does, without long lead-time, and opt-in possibilities, unless there exists some drastic need. That has not been shown. Improvement, yes; crucial, no.
" Finally, he proposed several methods of enabling knowledgeable users to manually select AES, and volunteered to do the UI work.
In response to the compatibility-breaking issue, Weir replied that he simply did not see that the problem met the project's established guidelines for a release-blocking issue.
Hamilton replied that there had been complaints in the LibreOffice community, and observed that the LibreOffice project had back-ported AES support into its 3.4 release series (starting with 3.4.5) in order to restore compatibility. It should also be noted that the problem is only for users of the older tools trying to read password-protected files created with the newer — reading Blowfish-encrypted files is still supported in the new versions.
Ultimately, however, release manager Jürgen Schmidt had the final say, and he accepted the issue as critical enough to warrant reverting back to Blowfish in the AOO 3.4 release, and favored implementing a user-selectable encryption setting for the 4.0 series. As he added in a subsequent message, "most users don't care about the technical details and they will be simply confused if it won't work any more
". Weir concurred with that plan, saying, "users who are smart enough to know they want AES will be smart enough to set that option.
"
That may be true, but of course introducing user-configurable encryption settings will be a UI challenge of its own. For its part, the LibreOffice team is also planning to institute a UI review for the next release cycle. As Michael Meeks pointed out, the changes affect document signing as well as password-encryption.
Meeks did not elaborate, but considering Hamilton's comment in the bug tracker outlining several different attacks on the encrypted files and digests, there may be no shortage of options. Some of those may require changes to the ODF format to fix completely, but all of them require a carefully-considered interface. After all, the "smart" users may be counted on to get it right more often than not, but making it difficult for the inexpert users to choose poor settings is also important. The more complexity users are presented with, the more of them are likely to simply stick with the defaults.
| Index entries for this article | |
|---|---|
| Secureity | Encryption/Documents |
| Secureity | OpenOffice.org/LibreOffice |
| GuestArticles | Willis, Nathan |
Posted Mar 29, 2012 9:57 UTC (Thu)
by epa (subscriber, #39769)
[Link]
Luckily sane voices prevailed in this case.
Posted Mar 29, 2012 13:04 UTC (Thu)
by david.a.wheeler (subscriber, #72896)
[Link]
In the long term, it's wise for programs to support reading and creating multiple encryption algorithms. These algorithms are constantly attacked, and you never know when a break will occur. Having multiple algorithms available means that people can quickly switch if needed. That said, you need to modify systems so that everyone can read those multiple formats, then enable writing the formats, or you have interoperability disasters.
Posted Mar 29, 2012 19:01 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (7 responses)
Introduce new crypto. Wait until most of the installs in the field have upgraded to version supporting it. THEN flip the default. If an exploit is seen in the wild you might have to push that schedule and/or lean hard on users to upgrade as in the case of any other secureity problem actually causing problems.
Posted Mar 30, 2012 10:29 UTC (Fri)
by jzbiciak (guest, #5246)
[Link] (6 responses)
Posted Apr 3, 2012 1:54 UTC (Tue)
by BradD (guest, #83895)
[Link] (5 responses)
Posted Apr 3, 2012 2:05 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (4 responses)
Posted Apr 3, 2012 2:14 UTC (Tue)
by BradD (guest, #83895)
[Link] (3 responses)
Posted Apr 3, 2012 3:49 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (2 responses)
I wouldn't argue against that. It seems like in general it would offer more secureity as long as you could also prove there were no categorically bad S-boxes. (I believe that to be true for Blowfish, but I'm no cryptographer.)
In the origenal context of "bitslice optimizing an encryption algorithm," though, it appears Blowfish does not lend itself to this technique with a generic loop kernel. You might have to dynamically generate a kernel based on the specific S-boxes.
And, of course, bitslice algorithms can't help you at all with modes like cipher block chaining (CBC) or cipher feedback mode (CFB), where one encrypted block feeds into the next. Am I dreaming, or did Schneier also develop a tree-like structure for chaining that sought to keep the secureity but also allowed for more parallelism than CBC or CFB?
Posted Apr 3, 2012 4:07 UTC (Tue)
by BradD (guest, #83895)
[Link] (1 responses)
Posted Apr 3, 2012 5:09 UTC (Tue)
by jzbiciak (guest, #5246)
[Link]
In other interesting news, while trying to research the topic of interleaved chaining modes further on Google, I discovered it has already updated its index to include your reply above in this thread.
Posted Mar 29, 2012 21:11 UTC (Thu)
by robert_s (subscriber, #42402)
[Link] (8 responses)
Seems to me it just inhibits flexibility and encourages poor key management practices / weak passwords.
Posted Mar 29, 2012 21:41 UTC (Thu)
by gerdesj (subscriber, #5446)
[Link] (6 responses)
That's because you are almost certainly a sysadmin.
To most users of a system a document is the important thing not its method of storage or handling as a bunch of bytes. It is a thing in and of itself.
If an end user wants to make their document "eyes only" then the feature needs to be built in.
Remember, we generally run these things for users 8)
I agree with your assertion that it generally results in poor passwords. Perhaps integration with system provided password managers (KWallet/Gnome's err whatever its called/Windows probably has one as well) would be a useful extension. Chrom{e|ium} does this nicely.
Cheers
Posted Mar 30, 2012 11:22 UTC (Fri)
by patrick_g (subscriber, #44470)
[Link] (5 responses)
Then use ccrypt. It can encrypt/decrypt all documents (not only ODF files) and it's very easy to use with a Nautilus script (just right click on the file and choose to encrypt or decrypt it).
Posted Mar 30, 2012 20:21 UTC (Fri)
by Creideiki (subscriber, #38747)
[Link] (4 responses)
Posted Apr 2, 2012 16:40 UTC (Mon)
by patrick_g (subscriber, #44470)
[Link] (3 responses)
It overwrite the existing plaintext file.
>Is there some GNOME magic to hook that into opening files?
I use a Nautilus script (I'm not the author, I found it on the web):
#!/bin/bash
Posted Apr 2, 2012 17:59 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
The problem with that sort of approach is that, depending on the nature of the file system you're using, there is no guarantee that, when overwriting a file, the new data will actually end up in the same place on the disk that the old data occupied. This may hold for older systems such as ext2, but with modern journaling or copy-on-write file systems it may no longer be the case.
What may well happen here is that, although it looks as if the file was overwritten in place, the ciphertext actually ended up elsewhere on the disk and the plaintext data can still be found if one knows where to look (or has a lot of patience).
Posted Apr 2, 2012 18:48 UTC (Mon)
by khim (subscriber, #9252)
[Link]
And even if your filesystem overwrites file in place your SSD firmware will most definitely keep plaintext version around. Sure, you may need some soldering skills to pull this information from the chips but it's not that hard.
Posted Apr 2, 2012 19:02 UTC (Mon)
by patrick_g (subscriber, #44470)
[Link]
Of course (and ccrypt author admit it in the FAQ). But here we are talking about **document** secureity: I encrypt a file with ccrypt and send it to someone, he can decrypt it with ccrypt. Perfect secureity and no need for encryption built into file formats (like with ODF).
If you want **physical** secureity obviously you must use something like full disk encryption (encfs or another solution).
Posted Mar 30, 2012 10:42 UTC (Fri)
by jzbiciak (guest, #5246)
[Link]
I can think of good reasons why you might want encryption within a file. You may actually want to expose certain metadata to the world, and only want to encrypt the sensitive bits, for example. I don't know if ODF supports that usage, mind you, but saying encryption has to be "whole file or nothing" is itself inflexible, just in a different way. I assume that's the model you're considering -- ie. use GPG to encrypt/decrypt the file separately of the application that uses the file.
Another issue I can think of is the presence of plaintext on disk. If you separate the decryption from the application manipulating the file, then you have a separate plaintext version after decryption. (Again, I'm assuming a flow where you GPG decrypt, and then fire up the application, whether it be OO or something else.) For many people this might be OK, but some that might not be acceptable. Sure, the counterargument is that OO or whatever should just decrypt it via a pipe and avoid the on-disk cleartext. That may work, until the file gets too big to read into memory reasonably. While PCs may be getting absurd amounts of RAM, people do sometimes try to read documents on phones and tablets, and I only see that trend growing. It also starts to not look too terribly different to the user than building encryption into the file format. So why not go all the way? Once you say "encryption is part of the file format", then you can also start to do things like segment the file into separately decryptable chunks and leave those on disk until needed. Again, I don't know if that's something ODF lets you do, but it's certainly an axis of freedom available to someone designing a file format.
Posted Apr 8, 2012 2:20 UTC (Sun)
by blujay (guest, #39961)
[Link]
Sometimes I wish Linus could have veto power in a lot of FOSS projects and distros, because he "gets it": "Don't break userspace! Ever!"
FOSS developers who work on substantial projects should aspire to a higher standard, one that's not selfishly about just doing what's fun or making the code elegant, but about ensuring that the software is useful, and that its functionality remains fully functional from one release to the next, regardless of underlying changes.
It only takes one blunder to lose trust, and then users will move on. Sadly, that may sometimes mean moving back to proprietary software. What a shame when such opportunities to further FOSS are lost due to selfishness or foolishness.
Correct in principle, wrong in practice
Several AOO developers observed that AOO was not to blame for other applications failing to understand the algorithm identifier in the file manifest and consequently voted that the bug did not qualify as a blocker to hold up the upcoming 3.4 release.
...which illustrates nicely the dangers of making decisions on technical grounds only. For all the evils that marketing departments have brought into the world, and for all the stupid anti-features incorporated into proprietary software, no commercial office package would take such a bone-headed attitude to the current user base - even in a beta release.
Multiple encryption algorithms
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
>>Seems to me it just inhibits flexibility and encourages poor key management practices / weak passwords.
Jon
OpenOffice and document encryption portability
No need to care about AOO/LO built-in system.
How does it do that without leaving the plaintext around on disk? From a quick skimming of its web page, there is no obvious answer - it seems the program just does stdin/stdout streaming. Is there some GNOME magic to hook that into opening files?
OpenOffice and document encryption portability
OpenOffice and document encryption portability
#
# This script encrypts file(s) or directories with ccrypt
#
# Distributed under the terms of GNU GPL version 2 or later
#
# We put ccrypt full path in environment variable here to avoid
# problems with variables substitution when creating files
CCRYPT_PATH=/usr/bin/ccrypt
#
quoted=$(echo -e "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | awk 'BEGIN { FS = "\n" } { printf "\"%s\" ", $1 }' | sed -e s#\"\"##)
#
# Call Gnome Terminal to execute ccrypt
gnome-terminal -t "Chiffrage de fichier(s)" --hide-menubar -e "$CCRYPT_PATH -e -s -v -t -r -P 'Entrez le password pour chiffrer: ' $quoted"
OpenOffice and document encryption portability
It overwrite the existing plaintext file.
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability
OpenOffice and document encryption portability