On Thu, Sep 1, 2011 at 4:11 PM, Dennis E. Hamilton <[email protected]> wrote: > 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. >
It is still declarable even if we are simply enabled for using a 3rd party service. So, for example, if we make calls into an OS-level URL protocol handler that negotiates SSL for https URL's, then that would count. That is my reading of it. > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:[email protected]] > Sent: Thursday, September 01, 2011 12:32 > To: [email protected] > 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 > <[email protected]> wrote: >> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <[email protected]> wrote: >>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <[email protected]> wrote: >>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin >>>> <[email protected]> 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 >> > >
