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.
2. While producing and consuming aes256 is allowed in the specification, there is not even
a "should" with respect to it.
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.).
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.
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).
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.
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:robweir@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.hamilton@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_Bauer@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.bircher@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/
>>> >
>>
>
>