On Sat, Sep 17, 2011 at 1:26 PM, Pedro Giffuni <giffu...@tutopia.com> 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": http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm#1111 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? -Rob > Pedro. > > On Sat, 17 Sep 2011 12:47:59 -0400, Rob Weir <robw...@apache.org> wrote: >> >> On 9/17/11, Mathias Bauer <mathias_ba...@gmx.net> 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 >>> > >
