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] Issue Comment Edited: (OFFICE-2563) ODF 1.2Part 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=18708#action_18708 ] 

Dennis Hamilton edited comment on OFFICE-2563 at 4/19/10 10:20 AM:

This has been superseded by a later issue, OFFICE-2639

      was (Author: orcmid):
    This has been superseded by a later proposal.
> 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: Schema and Datatypes, Security
>    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
>            Assignee: Michael Brauer
>             Fix For: ODF 1.2 Part 1 CD 5
> 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]