Update. By golly, OpenOffice.org 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 [mailto:dennis.hamil...@acm.org] Sent: Thursday, September 01, 2011 13:12 To: ooo-dev@incubator.apache.org 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. Rob, 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 OpenOffice.org deals with SSL certifications, but I guess I should be prepared for anything. - Dennis -----Original Message----- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, September 01, 2011 12:32 To: ooo-dev@incubator.apache.org 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 compatibility. 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. -Rob On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin <robertburrelldon...@gmail.com> wrote: > On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dwhyt...@gmail.com> wrote: >> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <r...@robweir.com> wrote: >>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin >>> <robertburrelldon...@gmail.com> wrote: >>>> Following the instructions[3], step 1 is to work out whether OOo has >>>> any unusual cryptography beyond ECCN 5D002, which is: >>>> >>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify> >>>> 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 > http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13 > > Robert >
