incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Request dev help: Info for required crypto export declaration
Date Fri, 02 Sep 2011 15:55:26 GMT
Update.  By golly, from 2.4.1 through OOo-Dev 3.4.0 will read (and unlock) .doc
files that are encrypted with the Microsoft Office 97/2000 procedure.  OO.o 2.4.1 will not
produce such .doc files, but OOo-Dev 3.4.0 and LibreOffice 3.3.3 will.

The only case supported in and out is the Microsoft Office 97/2000 method.  It appears that
none of the better choices in Office 2003 (Base, Strict, and a variety RC4-oriented ones,
all with specifiable key size) are supported.  I didn't try the ancient XOR method to see
if that would be ingested by any OO.o implementations.

More for the list of places to identify in the code.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [] 
Sent: Thursday, September 01, 2011 13:12
Subject: RE: Request dev help: Info for required crypto export declaration

I'm not aware of any "legacy encryption" in non-ODF formats being supported on output or input.
 I must try that.


Is it your understanding that http is implemented directly in OpenOffice, or is the platform
provider of http: and https: schemes relied upon?  I would be amazed to learn that
deals with SSL certifications, but I guess I should be prepared for anything.

 - Dennis

-----Original Message-----
From: Rob Weir [] 
Sent: Thursday, September 01, 2011 12:32
Subject: Re: Request dev help: Info for required crypto export declaration

So in general OpenOffice supports encryption and digital signatures
and https/SSL.  So we have support for standard algorithms, from
one-way hashes like SHA-1, to block encryption like Blowfish and
AES-256,  to public key cryptography per the W3C's XML Digital
Signatures.   We also support legacy Microsoft Office encryption
algorithms that are generally weaker and used only for backwards

I'm not a crypto expert, so I'm not sure what something exotic would
look like.  I think the strongest thing we have is AES-256.


On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
<> wrote:
> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <> wrote:
>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <> wrote:
>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>>> <> wrote:
>>>> 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?
>>> For example, Calc has a ROT13() spreadsheet function, which
>>> undoubtedly is a weak symmetrical encryption technique, certainly not
>>> one with a key length in excess of 56-bits.
>>> So what now?  In other words, I'm puzzled by the "in excess" part.
>>> They seem to be saying that strong encryption is regulated less than
>>> weak encryption.
>>> Could you explain where I'm getting this wrong?
>> It looks to me like the key phrase is "any unusual cryptography beyond
>> ECCN 5D002", and the definition of that phrase is the cited block, as
>> opposed to the cited block being a definition of ECCN 5D002.
>> I am having a remarkably hard time finding a definition of ECCN 5D002.
> EAR 740.13(e) should be on
> Robert

View raw message