On Sat, Sep 17, 2011 at 1:07 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > Concerning interoperability with Microsoft Office applications, > > 1. As far as I know encrypted ODF documents in any form are not accepted by > Microsoft Office applications and there is no expectation that they are. > > 2. As far as I know, OpenOffice.org does not support any of the stronger > encryption methods in Office 97-2000 and 2003 documents. Any superior > encryption applied to OOXML documents is also not accepted. Nor does export > from OpenOffice.org to Microsoft Office formats appear to support any > Password Protection beyond the weaker of those supported at even the Office > 97-2000 level. The OpenOffice.org user is not given any options to choose > among. > > 3. It would be interesting to know which levels of encryption of Microsoft > Office documents have been accepted for use in exchange or handling of > official documents. It would also be interesting to know how such > qualification was achieved. I have no idea. >
It occurs through FIPS 140 certification. Here's an example of how this is invoked from a regulation: http://www.gpo.gov/fdsys/pkg/CFR-2010-title48-vol4/pdf/CFR-2010-title48-vol4-sec352-239-71.pdf "352.239–71 Standard language.for encryption" As prescribed in 339.101(d)(2), the Contracting Officer shall insert the following clause: STANDARD FOR ENCRYPTION LANGUAGE (JANUARY 2010) (a) The Contractor shall use Federal Infor- mation Processing Standard (FIPS) 140–2- compliant encryption (Security Require- ments for Cryptographic Module, as amend- ed) to protect all instances of HHS sensitive information during storage and trans- mission." So to do business with the agency (in this case Department of Heath and Human Services) you need to be using validated encryption modules. This requires the use of approved algorithms. > I don't follow the logic of communicating with people directly relying on the > OO.o code base only if we also invite in the United Nations General Assembly. > In any case, I am communicating with LibreOffice on matters of this kind as a > private citizen (sort of Jimmy Carter in the small). I will not report back > here. I think communication bridges are better served if LibreOffice experts > and those of other related products speak for themselves here. > > I shall not continue any further on this line concerning presumptive user > requirements. > This is not presumptive. US Federal regulations are published online Anyone can look them up, Similar regulations exist in Europe and in Japan. > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Saturday, September 17, 2011 09:40 > To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org > Subject: Re: AOOo can't save passwort protected file > > 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/ >>>>> > >>>> >>> >>> >> >> > >
