I am not making a judgment in the case of encryption used as part of digital-signature PKI-based methods. We need to identify them regardless.
I also don't know if those particular encryptions are done in OpenOffice.org code or are handled by the platforms at runtime. This might vary depending on the platform. We need to comprehend such variations for interoperability purposes as well. - Dennis -----Original Message----- From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir Sent: Thursday, September 01, 2011 13:03 To: ooo-dev@incubator.apache.org Subject: Re: Request dev help: Info for required crypto export declaration On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> 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 -Rob > 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 OpenOffice.org. > I believe there are extensions in the builds but they are not currently > enabled in the standard distributions. > > 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 OpenOffice.org. > > 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 OpenOffice.org. > 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 [mailto:robertburrelldon...@gmail.com] > Sent: Thursday, September 01, 2011 12:14 > To: ooo-dev@incubator.apache.org > Subject: Re: Request dev help: Info for required crypto export declaration > > On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir <r...@robweir.com> wrote: >> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin >> <robertburrelldon...@gmail.com> wrote: >>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton >>> <dennis.hamil...@acm.org> wrote: >>>> Please just do it this way: >>>> >>>> <http://www.apache.org/dev/crypto.html> >>>> >>>> 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='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? > > 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 > >
