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: [OASIS Issue Tracker] Commented: (OFFICE-2563) ODF 1.2 Part 1 CD04:More Digest Algorithms are Wasteful and Burdensome

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834#action_17834 ] 

Dennis Hamilton commented on OFFICE-2563:

For external discussion of how stronger hashing is not the issue, and revealing the hashcode helps attackers, there is this passage in the Wikipedia discussion of SHA hash functions, http://en.wikipedia.org/w/index.php?title=SHA_hash_functions&oldid=345184306

"Some of the applications that use cryptographic hashes, such as password storage, are only minimally affected by a collision attack. Constructing a password that works for a given account requires a preimage attack, as well as access to the hash of the original password (typically in the shadow file) which may or may not be trivial [though it is when the hash is in an XML document]. Reversing password encryption (e.g. to obtain a password to try against a user's account elsewhere) is not made possible by the attacks [using a collision]. (However, even a secure password hash can't prevent brute-force attacks on weak passwords.)" [insersions are mine: dh]

For a general discussion of why secrets shouldn't be hashed, there is a 2008 post from Ben Adita, "Don't Hash Secrets" at http://benlog.com/articles/2008/06/19/dont-hash-secrets/ and I have a lengthy analysis of my own at http://orcmid.com/blog/2010/02/document-security-theater-when-key-is.asp

Concerning how wasteful it is to expand the set of authorized digest algorithms, think about the added complexity of conformance testing, interoperability confirmation, and many other increases in effort and cost among adopters as well as producers of compliant products.   It is all waste relative to the presumed increase in safety involving a feature that has no security value in the first place.  

> ODF 1.2 Part 1 CD04: More Digest Algorithms are Wasteful and Burdensome
> -----------------------------------------------------------------------
>                 Key: OFFICE-2563
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2563
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Table, Text
>    Affects Versions: ODF 1.2 Part 1 CD 4 
>         Environment: This issue applies to all forms of ODF 1.2 Part 1 CD04 and to previous version of ODF 1.2 working documents.  It does not apply to ODF 1.0 and ODF 1.1.
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2
> The introduction of table:protection-key-digest-algorithm (19.700) and text:protection-key-digest-algorithm (19.852) opens up the prospect of additional algorithms beside the default SHA1.  In fact, SHA256 must be supported by consumers and should be used by producers.  The current text also permits SHA512 and RIPEMD-160 by reference to [xmlenc-core].  Additonal algorithms, identified by other URIs, are also allowed.
> This is wasted effort.  The digest algorithm does not protect the protection, it only protects the key.  Furrthermore, having the hash of the key exposed and available, as it is in the table:protection-key and text:protection-key entries makes it easy to discover the key by well-known password attacks.  The only safe key to use in setting protection is one that is worthless for any other purpose and for which its discovery is no loss.   In general, hashes should not be used to protect secrets where the hash itself is readily obtained and where the secret is of any serious value.  The prospect of possible collisions that have the same hash is in fact uninteresting for this use case.  
> By requiring support for stronger digest algorithms in the specification, there is also an unnecessary burden on implementers, conformance assurance efforts, and just plain code bloat for no useful value.  
> My preference is that these attributes be removed from the ODF 1.2 specification altogether and that the requirement to use SHA1 be stated as part of the specification for table:protection-key and text:protection-key.  That's already more than enough.  (XOR folding would probably be sufficient but it is too late for that.).
> Acknowledging that the SHA256 recommendation is likely established in implementations, I propose that only SHA1 and SHA256 be permitted, there be no requirement on producers other than they use one, and no other digest algorithms be allowed or expected.

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


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