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