[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (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=30759#action_30759 ]
Dennis Hamilton commented on OFFICE-3703:
-----------------------------------------
ADJUSTING THE ITERATION-COUNT BYTE
In proposal version 1.05, the first byte of the 160 byte salt is used to hold a code for the iteration-count to be used. I still favor that usage, and it is consistent with what PKCS#5 says about ways to use salt codes, so long as there is enough effectively-random bits in there too.
But if the iteration-count code is included in the salt that is employed in the initial SHA1DK iteration, that means it must be fixed at the start of the iteration process.
I found an useful case where the producer of an SHA1DK protection-key value might only determine the iteration-count code by iterating and stopping at the highest value that satisfies some time constraint.
ADJUSTMENT TO THE ITERATION-COUNT CODE IN THE SALT:
I propose the following adjustment:
salt[0], the first byte, is used to carry an iteration-count code as defined already.
When the salt is used in the PBKDF2 operation to authenticate a password, the iteration-count code is removed and salt[0] is set to 0x01. The PBKDF2 iterations will be as defined by the removed iteration-count code.
In creating a protection-key value, the first byte of the salt is set to 0x01 and the remaining 19 bytes are cryptographically random bits. After PBKDF2-generated final 160 bits are produced, the salt[0] byte in the final 320-bit SHA1DK protection-key value is replaced by the iteration-count code for the number of iterations actually performed.
> 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]