Re: [office-comment] Insufficient documentation on ODF encryption.

[Brad Hards <bradh@frogmouth.net>]

On Monday 01 June 2009 01:26:11 am Wouter van Vugt wrote:
> -          The text immediately jumps into implementation steps, without
> explaining anything about the goals, process or general background of
> encryption of ODF documents. For instance, is the entire ZIP encrypted, or
> the entries within the ZIP?
I agree it could be easier to tell this. Section 17.3 does tell you that each 
file is encrypted, and then 'STORED' rather than 'DEFLATED', which should 
tell you that the content files in the zip are encrypted, rather than the 
whole document.

> -          There are no references to other important areas of the
> specification, which would facilitate improved navigation. This makes it
> even harder to find relevant areas of ODF to look at.
I agree, but 17.7 isn't that far away.

> -          There is no mention of decryption of a document.
I disagree. Blowfish is a symmetric cipher, so the process is obvious.

> -          The steps do not show any sample data which could be used to
> validate my code without needing to fall back on existing implementations
> (which might be equally wrong as my code)
I agree, however you should probably be using an existing library (e.g. 
openssl, libgcrypt or something equivalent) rather than re-implementing this 
stuff.

> -          The author of the Blowfish encryption algorithm indicates that
> he is amazed that it is even used. It might not be allowed to use the
> algorithm for FIPS compliancy (I'm no expert on that though).
This isn't anything to do with the spec. Blowfish (especially in CFB mode) 
might not be an obvious choice now, but there is a case for consistency with 
previous implementations, and it is a good algorithm.

> -          The encoding of the password is not mentioned, which is vital
> information to be able to implement this feature.
I partly agree. The management of the password is at least partly an 
implementation detail, and turning text into a byte stream isn't necessarily 
something that belongs here. Perhaps specifying UTF8 would help.

> -          The exact process of salting the password hash is defined as
> 'used together', which is totally useless from an implementation
> standpoint.
I disagree. In context:
"This salt is used together with the 20-byte SHA1 digest of the password to 
derive a unique 128-bit key for each file. The algorithm used to derive the 
key is PBKDF2 using HMAC-SHA-1(see [RFC2898]) with an iteration count of 
1024."
So the first part is introductory text (which you asked for!). The algorithm 
for key generation is fully specified given RFC2898, the HMAC algorithm, and 
the iteration count.

For what it is worth, I've implemented this without using OpenOffice source 
code (I'll admit to having had a quick look at the source tree and deciding 
that looking at an encrypted file to verify my understanding of 17.7 was 
easier).

Brad