incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: AOOo can't save passwort protected file
Date Sat, 17 Sep 2011 17:59:50 GMT
On Sat, Sep 17, 2011 at 1:26 PM, Pedro Giffuni <> wrote:
> Hi;
> Despite the valid interest in higher encryption schemes, I
> prefer to set Blowfish as default now. That doesn't mean
> we won't consider patches later on, of course.
> BTW, can't we just use OpenSSL? I think it's included in
> most linux/BSD distributions.

OpenSSL is a a validated module when run in "FIPS mode":

But that would still apply to AES, not Blowfish.

Think of it this way:  FIPS 140 defines what the acceptable algorithms
are.  Then the actual modules, the actual libraries, are validated by
3rd party testing labs according to NIST criteria.   If we use
validated modules implementing approved algorithms, then we're golden.

I'd be happy if we had deep in some configuration dialog the ability
for user (or more likely the IT department) to specify the algorithm
to use.

The question of the default setting is less critical.  The
organizations that are most concerned about crypto tend to also be the
organizations that will customize their installs to override the
default settings for all users in their organizations.  So if we want
the Apache-released version to use Blowfish by default, that is fine.

This is something that we should keep in mind in general.  Microsoft
does a great job with their Office Resource Kit and the ability for
corporate users to customize and deploy installs in their
organizations with different defaults.  We should aim for similar
capabilities for AOOo,.

So think of two kinds of users;

1) Those who download a single copy of AOOo and install it on a single
machine, or a small number of machines.

2) Those who customize the install, add additional corporate
templates, override settings, etc., and deploy to thousands of users.

We might have great ideas for what settings we have as defaults for
that first class of users.  But we should also enable IT departments
to enforce their own requirements for their own users.  The defaults
appropriate for installing on 40 machines for use by patrons in a
public library might be different than the defaults for 100,000 users
at a Fortune 500 company.

Does that make sense?


> Pedro.
> On Sat, 17 Sep 2011 12:47:59 -0400, Rob Weir <> wrote:
>> On 9/17/11, Mathias Bauer <> wrote:
>>> Am 17.09.2011 14:44, schrieb Rob Weir:
>>>> 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.
>>> As you said, OOo *1.3* will *recommend* it. Does that require postponing
>>> an AOOo 3.4 release until there is a code replacement for nss? Or do you
>>> already have something to use? IIRC it took roughly two weeks to
>>> implement and test the new AES code for an engineer familiar with the
>>> code. I assume that for a newbie that would be quite some time more.
>> Support for AES exists in the JCE and via the ODF Toolkit.  The later
>> is Apache 2.0 licensed.
>>> IMHO getting 3.4 out fast is important. And of course having AES
>>> encryption is important also - immediately after that.
>> I'm flexible on the staging of this.  Eventually we'll want to get to
>> have full AES support.  I've seen Microsoft push OOo out of
>> consideration for government accounts by arguing that the MS Office
>> crypto is certified and ours is using an algorithm (Blowfish) that is
>> not, that OOo uses a cipher that even the author recommends not using.
>>  We don't win that debate with a backwards compatibility argument.
>>> YMMV.
>>> Regards,
>>> Mathias

View raw message