Re: [office] RE: (office-comment) Insufficient documentation on ODFencryption.

[robert_weir@us.ibm.com]

Dennis, if you're looking for your ideas to be considered when we work on 
the packaging part, then you want to transcribe your points into one or 
more JIRA issues, or add your analysis as a comment to the original public 
comment (OFFICE-1840).

I'm sure we can address these points to everyone's satisfaction when we 
get to packaging.  In fact, we can probably process some of these 
amplifications as errata for ODF 1.0/1.1 if there is interest.

Regards,

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/01/2009 
06:10:04 PM:
> 
> 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.
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>