openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Request dev help: Info for required crypto export declaration
Date Thu, 01 Sep 2011 20:03:04 GMT
On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
<> wrote:
> Let me see if I can help ground this.

Remember, the export could be of code, not just the binaries.  So if
we have code that does asymmetrical encryption, then we are exporting
that, even if in the binaries we call it only in the context of
digital signatures.  Or not.  That seems obvious to me, but IANAL


> 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
 I believe there are extensions in the builds but they are not currently enabled in the standard
> 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
> 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  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
> -----Original Message-----
> From: Robert Burrell Donkin []
> Sent: Thursday, September 01, 2011 12:14
> To:
> 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:
>>> <blockquote cite='>
>>>   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).
>>> </blockquote>
>>> 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

View raw message