Visible Hashes and PBKDF2

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Bart, David, and Rob

I see this on-list exchange as a matter of mutual education on the context
and what the existing provisions are.  There is no particular problem
although there are a couple of wordings in CD05 that reflect incomplete
resolutions of some issues (some effected wordings were not caught in the
resolution).  

There were previous issues on this topic and I also did considerable
analysis.  There might need to be a branch off of a previously-resolved
issue to correct some small glitches that have crept into later drafts of
ODF 1.2 where it can be seen that the application of previous resolutions
needs further adjustment (e.g., remove contradictions because a related
paragraph was left unchanged).  But the intention has already been reflected
in existing JIRA issues, and the adjustments I see now are quite
straightforward.

   *   *   *   *   *   *   *   *

With regard to having a URI for PBKDF2, the problem is that PBKDF2 is not a
single method, it is a framework of methods.  Finally, there is no mention
of PBKDF2 in [xmlenc-core], which is what we have been using.

PBKDF2 requires a supplied Pseudo-Random Function (typically an HMAC but it
can be one of many) and there are specifications that are needed with regard
to the size of the key to be produced (PBKDF2 can produce very large keys in
terms of bits, in terms of entropy, different story).  Finally, there are
whatever the input conditioning/constraint is for starting up a PBKDF2.
PBKDF2 specifications (in RSA documents and NIST materials, as I recall)
deal with the internal padding operations that are required and how data
passes to successive iteration stages.  It matters what conditioning is done
for the password that PBKDF2 starts with.  For Blowfish CFB, the password is
turned into a start key using SHA1, and that is used in the PBKDF2 as the
password from which the key is derived.   This is a pre-PBKDF2 convention
and not part of PBKDF2 which can start with a password of pretty much any
length and do its own conditioning to get down to the size used in the
iterations.

There is an xmlenc-core1 currently in Working Draft, so we can't reference
it, <http://www.w3.org/TR/xmlenc-core1/>.  However, if you look at section
5.4.2 of that draft, it will be seen that it is specified by a complex
element that requires a salt procedure, an iteration count, an output key
length, and a Pseudo-Random Function (PRF) as parameters.  The *default PRF*
in the current draft of xmlenc-core1 is hmac-sha1.  This element is expected
to be used in an <xenc11:PBKDF2-params> element of an
<xenc11:KeyDerivationMethod> element and that is not related to the novel
but potentially valuable use of PBKDF2 as a password verification procedure.

That's why the *specific* parameterization of PBKDF2 that is used with the
ODF Blowfish CFB has been spelled out in the ODF 1.2 update on the legacy
encryption algorithm.  (I need to check how much the existing JIRA issues on
this are reflected in the current CD05 editor draft and make sure the
resolutions are completed.  That's one of my commitments for today.)
 
 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Sunday, October 31, 2010 02:13
To: David LeBlanc; dennis.hamilton@acm.org; 'ODF TC List'
Subject: RE: [office] The problem of visible hashes for protection keys

David,

> I do not know if there's an algorithm URI for PBKDF2, but seems like there
ought to be.

There is one in XML-ENC 1.1:  http://www.w3.org/2009/xmlenc11#pbkdf2

(or did you mean in the ODF spec ?)


Best regards

Bart
---------------------------------------------------------------------
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