From ooo-dev-return-4679-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Thu Sep 1 19:58:59 2011
Return-Path:
X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 096E9883B
for ; Thu, 1 Sep 2011 19:58:59 +0000 (UTC)
Received: (qmail 1366 invoked by uid 500); 1 Sep 2011 19:58:58 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 1308 invoked by uid 500); 1 Sep 2011 19:58:58 -0000
Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: ooo-dev@incubator.apache.org
Delivered-To: mailing list ooo-dev@incubator.apache.org
Received: (qmail 1300 invoked by uid 99); 1 Sep 2011 19:58:57 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2011 19:58:57 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.hamilton@acm.org designates 75.98.160.130 as permitted sender)
Received: from [75.98.160.130] (HELO a2s15.a2hosting.com) (75.98.160.130)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2011 19:58:52 +0000
Received: from 63-226-210-225.tukw.qwest.net ([63.226.210.225] helo=Astraendo)
by a2s15.a2hosting.com with esmtpa (Exim 4.69)
(envelope-from )
id 1QzDPD-0004Kz-9V
for ooo-dev@incubator.apache.org; Thu, 01 Sep 2011 15:58:31 -0400
Reply-To:
From: "Dennis E. Hamilton"
To:
References: <4E5E3E79.6080206@gmx.net> <00c701cc67fb$193ca9c0$4bb5fd40$@acm.org> <010c01cc68d6$6b44c1e0$41ce45a0$@acm.org>
In-Reply-To:
Subject: RE: Request dev help: Info for required crypto export declaration
Date: Thu, 1 Sep 2011 12:59:44 -0700
Organization: NuovoDoc
Message-ID: <013501cc68e1$b2834760$1789d620$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJRvwQ0LcPgZoeUpBIduQz/HePbgAIHneuoAwu04o0CfbDY0AHeL+yIAZlS8GsCIfwkhwJTL+7KAZaBxegB2geWRJOWzO+Q
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - a2s15.a2hosting.com
X-AntiAbuse: Original Domain - incubator.apache.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - acm.org
Let me see if I can help ground this.
Currently, digest algorithms are used for a variety of things. The =
common case is SHA1. These are not themselves a concern, as I =
understand it, since their function is not directly related to =
encryption even though they come into play in the use of encryption =
methods.
There is no support for *document* *encryption* via asymmetric keys. It =
is not specified in ODF and there is no way to do it in current =
implementations as far as I know.
There is *password-based* *document* *encryption*. The current default =
procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 =
using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are =
provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with =
"rng" methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish =
are allowed but I don't know the status of any implementation-dependent =
variations in OpenOffice.org. I believe there are extensions in the =
builds but they are not currently enabled in the standard distributions.
There is support for digital signatures using PKI methodologies and =
those do, of course, use *asymmetric encryption* as part of the =
signature procedure. We need to catalog what those flavors are that are =
accepted and that are produced. Implementations are allowed =
considerable license in this area and we need to inventory the actual =
support in OpenOffice.org.=20
It is not clear to me that the asymmetrical encryption used for digital =
signatures is a concern, but it is useful to have all of these methods =
profiled and catalogued concerning their implementation in =
OpenOffice.org. Comprehensive profiling of digital signature provisions =
is required to ensure interoperability in any case.
I am not aware of any other cases. There are proposals for some modest =
but valuable modifications in ODF 1.3 and as possible =
implementation-dependent introductions in products supporting earlier =
versions of ODF. Any such implementations would need to be identified =
too, although none of those I am aware of introduce additional =
encryption algoritms.
- Dennis=20
-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]=20
Sent: Thursday, September 01, 2011 12:14
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export =
declaration
On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir wrote:
> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
> wrote:
>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
>> wrote:
>>> Please just do it this way:
>>>
>>>
>>>
>>> ASF is very clear on what is required for *its* releases and this =
page appears to be comprehensive.
>>
>> The Apache rules break down into reporting to users and notification.
>> Informing users is important but notification is urgent (making =
source
>> available [1] counts as export).
>>
>>> (I finally found where I saw this before. It has also been =
discussed here or on the ooo-private list before. I remembered it as =
being simpler than it is.)
>>
>> (It looks worse than it is)
>>
>> Following the instructions[3], step 1 is to work out whether OOo has
>> any unusual cryptography beyond ECCN 5D002, which is:
>>
>>

>> Software specially designed or modified for the development,
>> production or use of any of the other software of this list, or
>> software designed to certify other software on this list; or
>> Software using a "symmetric algorithm" employing a key length in
>> excess of 56-bits; or
>> Software using an "asymmetric algorithm" where the security of the
>> algorithm is based on: factorization of integers in excess of 512 =
bits
>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>> group of a finite field of size greater than 512 bits (e.g.,
>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>

>>
>> Does OOo rely on cryptography more exotic than this?
>>
>
> That is where it seems backwards to me. If I'm reading this
> correctly, we are OK if we use a symmetrical algorithm with key length
> greater than ("in excess of") 56-bits. But if we use an algorithm,
> with less thanb 56-bits we're considered exotic? Really?
Remember that we're only interested in strong cryptography :-)
IIRC symmetric and asymmetric algorithms weaker than this are not
considered strong cryptography, and so don't fall under ECCN 5D002.
Cryptography which is neither weak nor covered by those definitions
needs special handling.
Robert