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] [OASIS Issue Tracker] Created: (OFFICE-2726) ODF 1.2Part 3 section 4.8.9 manifest:key-derivation-name description

It is correct that it is insufficient to specify just the KDF. You also have to specify the digest algorithm used - IIRC, HMAC is implied, and you only have to say sha-1, but I should double-check that. In addition, the number of bytes of salt should be specified, along with the spin count.

IMHO, we should replace the encryption with something better and more flexible, and the standard should just accurately document the existing encryption approach, and not seek to branch it such that we end up with 3 approaches (original, original + variants, new). That is, unless there are existing implementations of original+variants, in which case it is worth discussing whether those should be in the standard. I'm trying to put my energy into defining 'new'.

-----Original Message-----
From: OASIS Issues Tracker [mailto:workgroup_mailer@lists.oasis-open.org] 
Sent: Wednesday, June 23, 2010 12:52 PM
To: office@lists.oasis-open.org
Subject: [office] [OASIS Issue Tracker] Created: (OFFICE-2726) ODF 1.2 Part 3 section 4.8.9 manifest:key-derivation-name description

ODF 1.2 Part 3 section 4.8.9 manifest:key-derivation-name description

                 Key: OFFICE-2726
                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2726
             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
          Issue Type: Bug
         Environment: This issue applies in all versions and drafts starting with the OASIS ODF 1.0 Standard.  The specific location, wording and proposed changes are against ODF 1.2 CD05 Part 3.
            Reporter: Dennis Hamilton

 1. In section 4.8.9 the first sentence is

"The manifest:key-derivation-name attribute specifies the name of the algorithm used to derive a name."

It should not end with "... algorithm used to derive a name."

It should say, "... password-based key-derivation algorithm used to derive a cryptographic key for use in encryption and decryption of the file."

 2. In the first bullet in the list following the second sentence, it says that a defined value for the attribute is

   "PBKDF2: The PBKDF2 key derivation method.  See [RFC2898].

This is incomplete.  PBKDF2 is a general procedure that depends on use of a Pseudo-Random Function (PRF) for its operation.  The choice of PRF must also be know in order for an encryption to be decrypted correctly.

One way to repair this is to add HMAC-SHA-1 to the definition as the understood PRF, using the procedure in the example in [RFC2898].

Finally, the size of the salt is relevant to the cryptographic strength of the key derivation.  64 bits is useful for implementation reasons, when HMAC-SHA-1 is the PRF.  Longer values are usable but more than 120 bits probably adds no further strength to the key derivation, no matter what key size is produced from the PBKDF2 derivation.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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:

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