On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton <[email protected]> wrote: > I think reverting to Blowfish with 8-bit CFB and the default algorithms is a > good idea regardless. >
I think that would be a very bad idea. We need to look beyond 2.4.1 compatibility and ask what the purpose of password protection is and how user uses it and why we switched to AES in the first place. If I was just sticking a file on the web for anyone to download it, then I'd have no knowledge or control over what application the user was using. In that case I'd personally use PDF. But if I needed the user to edit the doc then I'd post in ODF. But a password protected file? That is generally not a broadcast of a file to many unknown parties. It is typically a known-party document exchange. I can tell them that OOo 3.0 or above is required, I can respond if they have a problem. If I am password protecting a doc it is for data security purposes, not for interoperability purposes. So why did OOo have Blowfish in the first place. Flash back to 2000 when the OOo project started. Data Encryption Standard (DES) had been the most common method in use, especially in commerce. But it was known that the short key length (56 bits) would eventually be cracked. It was simply a matter of Moore's Law. One of the alternative algorithms at the time was Bruce Schneir's Blowfish, specified in a popular cryptography book at the time. It was especially attractive for OSS because the author made it available royalty free, So savvy OSS projects of the era, knowing that the DES key length was short. So that explains why OOo has it. And since OOo's format was the base of ODF 1.0, that explains why ODF has Blowfish. In parallel with this, the US government was running a competition for a replacement algorithm for DES. There were 15 submissions, including one by Bruce Schneir. But it wasn't Blowfish. It was a variation called Twofish. Twofish is used, for example, in OpenPGP. Bruce actually recommends today to not use Blowfish, but to use Twofish instead [1]. When the competition for a new algorithm ended, the winner was the Advanced Encryption Standard (AES). We really need to support that algorithm. There is a reason why ODF 1.3 recommends it. There are regulations in several countries that specify what cryptographic methods may be used for government work. In the US this is called FIPS == Federal Information Processing Standards. There are similar rules, for example, in Japan. FIPS 140-2 recommends AES. It does not recommend Blowfish. So this has great relevance for government users, government contractors, as well as other sectors like healthcare. >From an international perspective, AES is also specified via ISO/IEC 18033-3:2010. So it is more acceptable for international trade. So from strength perspective, from government requirements, to international acceptability, AES is the preferred algorithm here. However, I do appreciate the backwards compatibility concerns. Maybe the way to solve this is to ensure that when a document is "Save As" to ODF 1.0/1.1 compatible, that we always use Blowfish. But when we save ODF 1.2, then we use AES, per the ODF 1.2 recommendation. But we might have also a box that a user could click if the wanted to save an ODF 1.2 doc using Blowfish. But I would not recommend this as the default. Another factor is that in some countries and for some uses, an algorithm selected by the US government is received with some suspicion and there may be alternative national mandates. So it probably makes sense to ensure that this area of the product is extensible, so if someone wanted to add additional algorithms, it could be easily done. [1] http://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/ But it was effectively cracked in 1999. They key length (56 bits) was just too short and Moore's Law had caught up with it. Since it was know One of the submitted algorithms was Blowfish. > I have confirmed that when OOo-dev 3.4 is set to save in ODF 1.0/1.1 format, > it will use the default algorithms for Password protection of files, as > expected. > > I also confirmed that saving in ODF 1.2 and ODF 1.2 extended format, the > aes256 algorithm is used. The resulting encrypted document will fail on open > with any of these releases: > > OpenOffice.org 2.4.1 > OpenOffice.org 3.2.0 > LibreOffice.org 3.3.2 > LibreOffice.org 3.4.3 > Lotus Symphony 3 fixpack3 > > Note that the only algorithm required to be supported by ODF 1.2 Package > consumers is the default Blowfish CFB. Other algorithms are admissible, but > none are recommended in the ODF 1.2 specification and only the one is > required. > > - Dennis > > -----Original Message----- > From: Mathias Bauer [mailto:[email protected]] > Sent: Friday, September 16, 2011 15:40 > To: [email protected] > Subject: Re: AOOo can't save passwort protected file > > Hi, > > AOOo can't use the nss libraries as easily as it was possible in the > "old" OOo, so perhaps a fix would be to revert the default encryption > algorithm in AOOo from AES to Blowfish in 3.4 until we found a > replacement for the AES encryption code from the nss libs. > > I know that MPL libs can be used "in binary form" in Apache projects, > here's the wording: > > "Software under the following licenses may be included in binary form > within an Apache product if the inclusion is appropriately labeled: > (...)" (lists MPL 1.0 and 1.1) > > As most 3rd party software is included in binary form in release anyway, > I wonder what that means in practice. Perhaps somebody in the know can > explain that. > > Regards, > Mathias > > Am 16.09.2011 10:40, schrieb Chao Huang: > >> hi, Jürgen >> >> Yes, I built AOOo with argument "--disable-mozilla". I will try to >> rebuild AOOo without that arg. >> >> Do we have any alternative way to solve the problem quickly? For >> example, put mozilla library into someplace? Thanks! >> >> >> On Fri, 2011-09-16 at 10:30 +0200, Jürgen Schmidt wrote: >>> Hi Raphael, >>> >>> i assume you have built your office with at least --disable-mozilla, >>> correct? As far as i know the password encryption used some stuff from the >>> mozilla code. So there will be a problem. >>> >>> Juergen >>> >>> >>> On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher <[email protected]> wrote: >>> >>> > Hi Dennis >>> > >>> > Thank you for the test too >>> > >>> > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: >>> > >>> > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on >>> >> win32 to see if the problem existed previously. I was able to password >>> >> protect (encrypt) a simple Writer document. It saved and opened fine >>> >> (after >>> >> I gave the password again. >>> >> >>> > So this is maybe a regression >>> > >>> > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >>> >> open the document and never got to recognizing that it was encrypted. I >>> >> got >>> >> a bad XML message, suggesting that an encrypted file was being mistakenly >>> >> opened without decryption first. >>> >> >>> > I think, that has nothing to do with it. >>> > >>> > >>> > Greetings Raphael >>> > >>> > >>> > -- >>> > My private Homepage: http://www.raphaelbircher.ch/ >>> > >> > >
