OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.



"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/01/2009 
06:10:04 PM:
>   1. Regarding ODF 1.1 and IS 26300, the example manifest in ODF 1.1 is 
> correct.  (The schema-required manifest:checksum-type and 
> 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 
> 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 
> technically doesn't need to be in the manifest.  We can ignore that 
>   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 
> 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, 
> entered a single password and there is nothing in the section 17.7.4
> Checksum attribute description that suggests how these would be 
> 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 
> 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.). 
> 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 
> and character encodings applies to all uses of password digests in the 
> specification.  Specifications for the various digest algorithms start 
> a binary string of bits already set up to be hashed/digested.  The 
> setup and its constraints must be known for the digest result to be
> reproducible from one implementation (and platform) to another (e.g., 
> 3.2, below).
>   2.4 In my OO.o 2.4.1 exercise, the <manifest:algorithm> elements all 
> manifest:algorithm-name="Blowfish CFB".  Again, the specification does 
> provide the value for this attribute, and there is no reference, in the 
> specification, to an authoritative definition for the specified 
> 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 
> count and salt values are provided, as needed for decrypting the 
> package item.  Again, the value "PBKDF2" is not defined, although the 
> 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 
> (4) whether the HMAC-SHA-1 is used somehow in making the 20-byte SHA1 
> 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 
> and supplied to step (4), and that HMAC-SHA-1 is used internal to the 
> 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 
> has nothing to do with the pre-hashing of the password that is 
> 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 
> 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 
> sentence in order to be rigorous about what is the case.)
>   3.2 In either case, the encoding of the "entered password" and any 
> 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 
> 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 
> expected to be.
> The latest working draft of ODF 1.2 Part 3: Packages, can be found on 
> OASIS ODF TC page at the end of the list under "Technical Work Produced 
> the Committee",

> 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 
> interchange of ODF packages containing encrypted items (and elsewhere, 
> for locking table cells, etc.) must be specified.
>   b. The internal encoding of passwords as octet strings to be used 
> 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 
> the specific algorithms that go with them, with authoritative 
>   d. There must be explanation of what the manifest:checksum attribute 
> really is and how it is they come to be different for individual Zip 
> 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 
> 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 
> 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 
> > 
> > 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 
> > specification and not use any extra materials like the Open Office 
> > code. My goal of implementing this feature of ODF is made difficult 
> 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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]