incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <>
Subject Re: Request dev help: Info for required crypto export declaration
Date Thu, 01 Sep 2011 20:13:21 GMT
On Thu, Sep 1, 2011 at 8:59 PM, Dennis E. Hamilton
<> 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.


> 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
 I believe there are extensions in the builds but they are not currently enabled in the standard

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


> 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  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.

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.


View raw message