[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: (office-comment) Insufficient documentation on ODF encryption.
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. [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]