[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=30784#action_30784 ] Dennis Hamilton commented on OFFICE-3703: ----------------------------------------- CONSIDERATIONS FOR USE OF AN ITERATION-COUNT CODE Before producing an update of the proposal to include the simpiifications of the previous two comments, I wanted to explain the use of the iteration-count code value. I would also be interested in any slower-growing but still-exponential function that is easy to compute with integer arithmetic. USING A SINGLE-BYTE CODE The SHA1DK protection-key value carries a single-byte value that identifies the number of iterations used in deriving the authentication value from the user's password and a cryptographically-random salt value. The use of a single-byte value is intended to be easy to validate and to then use in performing the iterative salted-password hash for authentication. The single byte values from 0 to 20 represent iteration counts from 75,026 to 1,836,311,903. These can be contained in 32-bit signed-integer values. values from 21 to 47 correspond to values that all fit in 64 bit signed-integer values, the last value being a number that requires 50 bits to represent: 806,515,533,049,393. It is expected that such high iteration counts will never be used. Just in case, there is room for far larger iteration counts before a 64-bit counter is insufficient. The use of a single byte, encoding a limited set of interation-count values, is easy to check for infeasible values. These can be ones that require counters larger than a consumer employs. In addition, a consumer, possibly with user interaction, may determine a value to be infeasible because an unacceptable time would be required to perform the necessary iterations. For producers of SHA1DK protection keys, the range of employed iteration counts can be adjusted upward over time as platforms are able to perform more iterations in the same desired time range (250-500 milliseconds, say). Producers can adopt techniques that determine the rate at which iterations are being performed to stop at the largest coded iteration-count that is performed within a particular time window. The values of iteration-count codes are expected to gradually float higher as processing power increases over time. THE COMPRESSED RANGE OF ITERATION COUNTS SHA1DK specifies that the iteration counts are derived using Fibonacci numbers. These numbers grow exponentially. In practice, fewer than 1/5th of the 256-value single-byte codes will be used. The first 48 values will likely not be exhausted. It might be useful have more granularity, with smaller steps in the advance of successive count values. This would have more single-byte codes not becoming infeasible so early. It is tought to beat the Fibonacci progression for simplicity. Suggestions of ways to not grow so rapdily are welcome. For comparison, here are the first 48 S[0] iteration-count codes, the corresponding Fibonacci number, F[26+S[0]], and the number of bits required for the count value: S[0] n bits F(n) 25 17 75,025 0 26 17 121,393 1 27 18 196,418 2 28 19 317,811 3 29 19 514,229 4 30 20 832,040 5 31 21 1,346,269 6 32 22 2,178,309 7 33 22 3,524,578 8 34 23 5,702,887 9 35 24 9,227,465 10 36 24 14,930,352 11 37 25 24,157,817 12 38 26 39,088,169 13 39 26 63,245,986 14 40 27 102,334,155 15 41 28 165,580,141 16 42 28 267,914,296 17 43 29 433,494,437 18 44 30 701,408,733 19 45 31 1,134,903,170 20 46 31 1,836,311,903 21 47 32 2,971,215,073 22 48 33 4,807,526,976 23 49 33 7,778,742,049 24 50 34 12,586,269,025 25 51 35 20,365,011,074 26 52 35 32,951,280,099 27 53 36 53,316,291,173 28 54 37 86,267,571,272 29 55 38 139,583,862,445 30 56 38 225,851,433,717 31 57 39 365,435,296,162 32 58 40 591,286,729,879 33 59 40 956,722,026,041 34 60 41 1,548,008,755,920 35 61 42 2,504,730,781,961 36 62 42 4,052,739,537,881 37 63 43 6,557,470,319,842 38 64 44 10,610,209,857,723 39 65 44 17,167,680,177,565 40 66 45 27,777,890,035,288 41 67 46 44,945,570,212,853 42 68 47 72,723,460,248,141 43 69 47 117,669,030,460,994 44 70 48 190,392,490,709,135 45 71 49 308,061,521,170,129 46 72 49 498,454,011,879,264 47 73 50 806,515,533,049,393 > 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]