[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. 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]