incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <...@robweir.com>
Subject Re: Request dev help: Info for required crypto export declaration
Date Thu, 01 Sep 2011 20:31:01 GMT
On Thu, Sep 1, 2011 at 4:11 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> 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:robweir@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
> <robertburrelldonkin@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dwhytock@gmail.com> wrote:
>>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <rob@robweir.com> wrote:
>>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>>>> <robertburrelldonkin@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
>>
>
>

Mime
View raw message