On Thu, Sep 1, 2011 at 8:59 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > Let me see if I can help ground this. > > 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.
AIUI only encryption is of concern > 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. Ok > 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. Sounds likely to be strong cryptography falling under 'Software using a "symmetric algorithm" employing a key length in excess of 56-bits' > 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. +1 > 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. +1 > 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. So far, looks like OOo most likely has strong crypto but it's all fairly standard stuff. We should press forward with the notification required by law whilst auditing the code. Robert
