On 9/17/11, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > Rob, > > 1. There is no requirement in ODF 1.2 for consumers and producers to > support anything but the default Blowfish with 8-bit CFB. >
Well, there is no requirement to support Blowfish either. Encryption is an optional feature. But for a large class of import users, AES is mandatory. Maybe not according to the standard, but by regulation. > 2. While producing and consuming aes256 is allowed in the specification, > there is not even a "should" with respect to it. > Again, I'm talking about user requirements, not the standard. > 3. Unilateral change to only producing aes256 when the save mode is 1.2 or > 1.2 extended breaks all versions of earlier releases of OO.o, including > earlier 3.x ones. It also breaks code on other releases based on the OO.o > code base (LibreOffice through 3.4.3, Symphony through 3 fixpack3, etc.). > There are many things in OOo 3.4 that an earlier version of OOo might not be able to process. The nice thing about OOo is earlier users are able to upgrade for free. And they always will be. In any case, I think this is a tradeoff that we might allow the intelligent user to make for themselves, interop with older versions of OOo versus greater security. > 4. If aes256 were to be produced, it should be at user option with warning > to the effect that the security used may limit the password being accepted > on any software but that used to set the password. > There are some apps, like MS Office, that won't process Blowfish-encrypted documents either. Maybe we should give a warning on all password protected documents? > Since this is all still password-based security, and the biggest > vulnerability is direct attack on the password, upgrading the encryption > does not seem to be worth the disruption (unless the less-disruptive (4) is > pursued). > Maybe to you, and according to your personal work habits this might be true. But try to think of other users here, maybe users who are trained to use proper passwords, customers in industries and sectors who are required to use FIPS 140-2 compliant algorithms. > It would be good to put our heads together with LibreOffice and anyone else > considering any introduction of new encryption methods in password-protected > files. LO presumably has the copyleft code that is no longer usable by us. > I see no enabling of it in LO producers so far. > Maybe put our heads together with users. Wider exposure to customer uses of encryption might broaden our thinking on the topic. > Collaboration on staging and maintenance of interoperability seems like a > great opportunity in this area. The ODF Toolkit might provide some valuable > reference cases as well. > > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Saturday, September 17, 2011 05:45 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton > <dennis.hamil...@acm.org> 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:mathias_ba...@gmx.net] >> Sent: Friday, September 16, 2011 15:40 >> To: ooo-dev@incubator.apache.org >> 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 <r.birc...@gmx.ch> >>>> 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/ >>>> > >>> >> >> > >
