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-3703) Proposal: ODF 1.3 Protection-Key Enhancements


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

Dennis Hamilton edited comment on OFFICE-3703 at 6/25/12 10:25 AM:
-------------------------------------------------------------------

OBSOLETE COMMENT: THIS COMMENT AND ALL COMMENTS PRIOR TO JUNE 2012 ARE RELATED TO AN OBSOLETE VERSION OF THE PROPOSAL.  IN PARTICULAR, the sha1-salted case has been replaced by SHA1DK and that does switch to a PBKDF2 and HMAC-SHA-1 key generation technique for producing a password authentication code.
  *  *  *  *  *  *  *  *  *  *  *

I should point out some things about the sha1-salted case.  

1. It is important that the salt is concatenated after the password before sha1 is produced.  This prevents the use of a salted-setup and it has the salt slide around in the digested-message buffer depending on the length of the password.

2. It may be feasible to allow a variable length salt, with some minimum.

3. The minimum 160 bits used here was just to mimic the 160 bits of the digest itself, since it should make it harder to attack the password.  To make it harder, a salt of 512 bits guarantees that at least two message blocks will be hashed.  But if computational cost of the hash is what matters, a better choice would be a PBKDF2 algorithm using a salt, a large iteration count, and the sha1 HMAC.   These could all be considered as stronger than sha-any-salted in the sense that they make brute-force attacks much more computationally expensive.  

4. The apparently-random form with no password to attack can be more bits and it is probably useful to allow that to be variable length as well.  It should be at least 160 bits so that a down-level consumer that assumes it has an SHA1 digest will not go off the rails, and any discoverable password is a coincidence.

5. I have created some test documents for ODF 1.1/1.2 to test how they respond to protection keys of an unknown digest algorithm or length.  The idea is to calibrate as well as possible what the potential disruption is.

      was (Author: orcmid):
    I should point out some things about the sha1-salted case.  

1. It is important that the salt is concatenated after the password before sha1 is produced.  This prevents the use of a salted-setup and it has the salt slide around in the digested-message buffer depending on the length of the password.

2. It may be feasible to allow a variable length salt, with some minimum.

3. The minimum 160 bits used here was just to mimic the 160 bits of the digest itself, since it should make it harder to attack the password.  To make it harder, a salt of 512 bits guarantees that at least two message blocks will be hashed.  But if computational cost of the hash is what matters, a better choice would be a PBKDF2 algorithm using a salt, a large iteration count, and the sha1 HMAC.   These could all be considered as stronger than sha-any-salted in the sense that they make brute-force attacks much more computationally expensive.  

4. The apparently-random form with no password to attack can be more bits and it is probably useful to allow that to be variable length as well.  It should be at least 160 bits so that a down-level consumer that assumes it has an SHA1 digest will not go off the rails, and any discoverable password is a coincidence.

5. I have created some test documents for ODF 1.1/1.2 to test how they respond to protection keys of an unknown digest algorithm or length.  The idea is to calibrate as well as possible what the potential disruption is.
  
> Proposal: ODF 1.3 Protection-Key Enhancements
> ---------------------------------------------
>
>                 Key: OFFICE-3703
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3703
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Improvement
>          Components: Security, Table, Text
>    Affects Versions: ODF 1.0, ODF 1.0 (second edition), ODF 1.1, ODF 1.2, ODF 1.2 COS 1
>         Environment: This is an enhancement, described in terms of changes to OpenDocument-v1.2-os.
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.3, ODF 1.3 CSD 01
>
>
>    The use of password hashes in easily-discovered XML element and attribute values is subject to compromise of the hashed password.  Although the use    of increasingly-stronger digest algorithms may lengthen the time required    for carrying out a brute-force attack on the hash, memorable passwords    remain subject to compromise and the attack becomes easier as processor    technology advances.  Recent (June 2012) reveal that there is an explosive growth in hacks involving the discovery of passwords that are authenticated by use of unsalted digest algorithms.
>    
>  In addition, the presence of hashes in plain sight in XML documents allows the digest value to be easily compared with the same digest value elsewhere, revealing worthy targets to an adversary.  In addition, the digest value is easily removed/replaced.  And an extracted digest value can be repurposed for malicious purposes.
>    
> This proposal introduces two protection-key digest algorithms, AUTHZ160 and SHA1DK that are intended to mitigate risks associated with use of digest algorithms and provision of the digests in plain view in XML documents.  AUTHZ160, the recommended new default, uses protection-keys that are not derived from a password at all.  They are 100% protection against discovery of an actual password known to the user by analysis of the protection-key alone.  SHA1DK uses an AUTHZ160-sized cryptographically-random salt and an iterative key derivation procedure that makes discovery of a password by repeated trials very costly.  (SHA1DK and an extension, SHA1DKX, can be used to create tear-off secret authenticators for AUTHZ160 protection keys, even though a protection-key that includes all of the SHA1DK result is password based.)

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