RE: [office] The problem of visible hashes for protection keys

[robert_weir@us.ibm.com]

All excellent points, of course.  But in 12 hours now one will remember or 
find what you said, unless this was entered into JIRA.

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 10/30/2010 
10:45:51 PM:

> 
> RE: [office] The problem of visible hashes for protection keys
> 
> We only have the two attributes, *:protection-key and
> *:protection-key-digest-algorithm.  However, I think we had loosened 
what
> :protection-key carries as being the information for verifying a key, 
not
> always a direct hash of the key.  This would allow us to register 
algorithms
> beside the normal ones that specified a PBKDF2 method where the
> protection-key entry would encode the iteration count and a salt as well 
as
> the derived key used as the authenticator.  So we have an opening.  The
> language wasn't loosened up completely (it is a bit contradictory) so I 
am
> going to see if I can put in a quick fix.
> 
> I think adding a child element that handled the protection key would be 
too
> much of a stretch.  There is no digest-algorithm URI for PBKDF2 that 
works
> for this.  I looked before when digging into the encryption options for 
ODF
> 1.2.
> 
> -----Original Message-----
> From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com] 
> Sent: Saturday, October 30, 2010 19:29
> To: dennis.hamilton@acm.org; 'ODF TC List'
> Subject: RE: [office] The problem of visible hashes for protection keys
> 
> Just specifying a digest algorithm is a fairly major flaw. I believe 
that
> xml-enc has a way to express a real KDF. One aspect of this that has to 
be
> done is to not only specify the digest algorithm, but also the iteration
> count, so that future versions can increase the iteration count, and 
older
> versions can still consume it.
> 
> At the very least, you need something along these lines:
> 
> <PBKDF2-digest>
>   <DigestValue Algorithm="URI">base64 of hash</DigestValue>
>   <IterationCount>100000</IterationCount>
>   <SaltValue>base64 of salt</SaltValue>
> <PBKDF2-digest>
> 
> Where recommended Algorithm is sha-256, Iteration count is 100k, salt is 
16
> bytes of random data.
> 
> I do not know if there's an algorithm URI for PBKDF2, but seems like 
there
> ought to be.
> 
> While I recognize that it is late in the process, due to the severity of
> this flaw, I think it ought to get fixed for 1.2. If it was not actually
> defined as part of the 1.1 standard, let's define it as something solid 
that
> we don't have to change again later.
> 
> ________________________________________
> From: Dennis E. Hamilton [dennis.hamilton@acm.org]
> Sent: Saturday, October 30, 2010 6:19 PM
> To: David LeBlanc; 'ODF TC List'
> Subject: RE: [office] The problem of visible hashes for protection keys
> 
> There is a mistake in the previous note.  There is a
> <text:protection-key-digest-algorithm> option for <text:object-index>. I
> double-checked the schema and rechecked ODF 1.2 CD05, and it is indeed
> there.
> 
>  - Dennis
> 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Saturday, October 30, 2010 17:46
> To: 'David LeBlanc'; 'ODF TC List'
> Subject: RE: [office] The problem of visible hashes for protection keys
> 
> Nice analysis.  Thanks David,
> 
> Here are the places in ODF 1.1, with the attribute always storing a
> key-verification hash (now documented in ODF 1.2 as being SHA-1):
> 
> 4.4.1 Section Attributes, Protected Section subsection, 
text:protection-key
> attribute
> 
> 8.1.1 Table Element, Protected subsection, table:protection-key 
attribute
> 
> 8.5.1 Document Protection, table:protection-key attribute [applies to
> spreadsheets]
> 
> By virtue of sharing the sectionAttr RNG pattern defined in 4.4.1,
> protection keys are also allowed on the following elements: 7.3.2
> <text:index-title>, 7.3 <text:table-of-content>, 7.4
> <text:illustration-index>, 7.5 <text:table-index>, 7.6 
<text:object-index>,
> 7.7 <text:user-index>, 7.8 <text:alphabetical-index>, and 7.9
> <text:bibliography>.
> 
> In ODF 1.2, the additional attributes 
table:protection-key-digest-algorithm
> and text:protection-key-digest-algorithm are added to go with the
> corresponding table:protection-key and text:protection-key occurrences,
> except it is missing for <text:object-index>.  The default is SHA1 and 
ODF
> 1.2 consumers are required to support SHA256 also.  The digest 
algorithms
> are identified by IRI, and new ones can be added, but the explanation 
for
> 19.700 and 19.853 *:protection-key-digest-algorithm is a little strange. 
 I
> will turn in a JIRA issue on these and the omission if there are none
> already.
> 
>  - Dennis
> 
> 
> -----Original Message-----
> From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com]
> Sent: Saturday, October 30, 2010 16:20
> To: dennis.hamilton@acm.org; 'ODF TC List'
> Subject: RE: [office] The problem of visible hashes for protection keys
> 
> [ ... ]
> My recommendation is to use a real key derivation function to create a
> password verifier. It can be a bit of a problem to deal with versioning 
- if
> you change this, then an older version of the software obviously cannot
> verify the password. However, due to the severity of disclosing 
passwords,
> I'd tend to recommend against implementing a feature that exposes 
passwords
> in that manner.
> 
> Just how widespread is this past usage? I do not recall seeing it in the
> v1.1 spec, but I may have missed it. If this is something new to this
> version, I'd strongly recommend doing it right, even if there are 
existing
> implementations.
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> 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
> ---------------------------------------------------------------------
> 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 
> 
> 
> ---------------------------------------------------------------------
> 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 
>