RE: (office-comment) Insufficient documentation on ODF encryption.

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I don't understand the point to making some sort of comparison with OOXML.
I don't see any mention of it in Wouter's comment, and I am going to simply
focus on what there is to figure out about ODF (1.1 and 1.2).

The following information is not a response from the ODF TC. I have been
looking into this on the ODF Interoperability and Conformance (OIC) TC and I
am providing this information for possible value in clarifying Wouter's and
your examination of the topic.  I am concurrently posting it to the ODF TC
List for the background of the TC members and potential use in creation of
issues to be worked on for ODF 1.2.

CURRENT ODF 1.1 AND IS 26300 SITUATION

  1. Regarding ODF 1.1 and IS 26300, the example manifest in ODF 1.1 is not
correct.  (The schema-required manifest:checksum-type and manifest:checksum
attributes do not appear on the <manifest:encryption-data> elements, and
there is no other clue on how these values, especially
manifest:checksum-type, are coded.]

  2. I encrypted a simple document using OO.o 2.4.1 Writer just now.
According to the manifest, the following Zip items are individually
encrypted: 

  "Configurations2/accelerator/current.xml"  
  "content.xml"
  "styles.xml"
  "meta.xml"
  "Thumbnails/thumbnail.png"
  "settings.xml"

Note that the recommendation in ODF 1.1 is not that the thumbnail be
encrypted, but that a substitute be provided.  (It is not clear to me what
use there is for an encrypted thumbnail, although I thought the idea was
that it was findable and usable without examining the manifest and that it
technically doesn't need to be in the manifest.  We can ignore that here.)

  2.1 For each of them, the manifest:checksum-type="SHA1/1K".  The
specification does not define this value and there is no reference to any
source document that explains what particular SHA1 digest algorithm this
happens to be.

  2.2 For each of them, the manifest:checksum value is *different*.  Yet, I
entered a single password and there is nothing in the section 17.7.4
Checksum attribute description that suggests how these would be different
given the same password.  (I find this worrisome, actually.  It would be
very discouraging to discover that how these are different involves
disclosure of information that weakens the security of the document.)

  2.3 For the hashing of a password that is done for manifest:checksum there
is no indication of the character-set encoding of the password and any
character-set limitations on what can be used in the password (which is
presumed to come from some external source, operator dialog, etc.).  There
is no indication how the internal-storage encoding of the password is
arranged and padded in a buffer that is then subject to the mystery
"SHA1/1K" procedure.  Side note: This problem of permissible character set
and character encodings applies to all uses of password digests in the ODF
specification.  Specifications for the various digest algorithms start with
a binary string of bits already set up to be hashed/digested.  The preceding
setup and its constraints must be known for the digest result to be
reproducible from one implementation (and platform) to another (e.g., see
3.2, below).

  2.4 In my OO.o 2.4.1 exercise, the <manifest:algorithm> elements all have
manifest:algorithm-name="Blowfish CFB".  Again, the specification does not
provide the value for this attribute, and there is no reference, in the ODF
specification, to an authoritative definition for the specified procedure.
The initialization vector is provided here (since it is required for
decryption too.)

  2.5 Finally, in my OO.o 2.4.1 exercise, the <manifest:key-derivation>
elements all have manifest:key-derivation-name="PBKDF2" and the iteration
count and salt values are provided, as needed for decrypting the particular
package item.  Again, the value "PBKDF2" is not defined, although the prose
of section 17.7.6 mentions that only the PBKDF2 key derivation method is
supported and makes reference to [RFC2898].

  3. Referring back to section 17.3 on encryption, it is not clear in step
(4) whether the HMAC-SHA-1 is used somehow in making the 20-byte SHA1 digest
at the beginning or it is used after the 20-byte SHA1 digest is derived.
The text of step (1) makes it seem that an SHA-1 is somehow already computed
and supplied to step (4), and that HMAC-SHA-1 is used internal to the PBKDF2
procedure in deriving a key using the SHA-1 input, the salt and the
iteration count. That is certainly a permissible way to do this sort of
thing.

  3.1 The text of RFC2898 suggests that HMAC-SHA-1 is the underlying
pseudo-random function to be used internal to the PBKDF2 procedure and this
has nothing to do with the pre-hashing of the password that is apparently
part of the ODF-specific use of PBKDF2 for key generation.  However,
HMAC-SHA-1 *will* hash a long password down to a 20-byte digest, and this
might actually be what is meant in step (1).  (Since RFC2898 is a bit
flexible here, the profiling of it for ODF needs a little more than the one
sentence in order to be rigorous about what is the case.)

  3.2 In either case, the encoding of the "entered password" and any padding
for input to the SHA-1 digest procedure (or HMAC-SHA-1) is not specified, as
already mentioned in 2.3, above.  RFC2898 is typical in its starting with
bits and not knowing how the bits got there:

  "Throughout this document, a password is considered
   to be an octet string of arbitrary length whose 
   interpretation as a text string is unspecified. 
   In the interest of interoperability, however, it 
   is recommended that applications follow some 
   common text encoding rules."

  3.2 ODF is silent on what the comment text encoding rule for passwords is
expected to be.

ODF 1.2 DRAFT PROVISIONS

The latest working draft of ODF 1.2 Part 3: Packages, can be found on the
OASIS ODF TC page at the end of the list under "Technical Work Produced by
the Committee",
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#technical

Section 2.3 Encrytion does not appear to have been changed from ODF 1.1
section 17.3.

Section 2.8 Manifest file does not appear to have changed from ODF 1.1
section 17.7.

For ODF 1.2, it appears that the following need to be cleared-up:

  a. The allowed password character set that should/must be supported for
interchange of ODF packages containing encrypted items (and elsewhere, as
for locking table cells, etc.) must be specified.

  b. The internal encoding of passwords as octet strings to be used further
in cryptographically-based functions should/must be specified (and
elsewhere, etc.)

  c. There must be definition of the admissible manifest:checksum-type
attribute values (including "SHA1/1K" if that is one) and identification of
the specific algorithms that go with them, with authoritative references.

  d. There must be explanation of what the manifest:checksum attribute value
really is and how it is they come to be different for individual Zip item
encryptions when only a single password is used (if the results in OO.o
2.4.1 are what was actually intended here).

  e. Clarification of whether the password (in a-b, above) is pre-digested
before application of PBKDF2 and, if so, what the digest function is.

There are some existing public comments about this part of the ODF
specification, and this analysis may be applicable to those as well as the
comment from Wouter van Vugt.


-----Original Message-----
From: Peter Dolding [mailto:oiaohm@gmail.com] 
http://lists.oasis-open.org/archives/office-comment/200905/msg00045.html
Sent: Sunday, May 31, 2009 18:13
To: Wouter van Vugt
Cc: office-comment@lists.oasis-open.org
Subject: Re: [office-comment] Insufficient documentation on ODF encryption.

> http://lists.oasis-open.org/archives/office-comment/200905/msg00044.html
> I am attempting to implement ODF encryption (ODF 1.1 paragraph 17.3) and I
> am failing miserably. My goal was to purely use information within the ODF
> specification and not use any extra materials like the Open Office source
> code. My goal of implementing this feature of ODF is made difficult with
the
> lack of useful information in the ODF specification itself.
[ ... ]

Lot of how this works is in the draft 1.2 specification.   At the time
1.1 was drafted there was a lot of other thing going on unifying other
parts.  So this section got left up in the air.  Of course it would
pay to get the draft and read over and make sure it complete.  Many
eyes of course.

[ ... ]