[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] The problem of visible hashes for protection keys
We only have the two attributes, *:protection-key and *:protection-key-digest-algorithm. However, I think we had loosened what :protection-key carries as being the information for verifying a key, not always a direct hash of the key. This would allow us to register algorithms beside the normal ones that specified a PBKDF2 method where the protection-key entry would encode the iteration count and a salt as well as the derived key used as the authenticator. So we have an opening. The language wasn't loosened up completely (it is a bit contradictory) so I am going to see if I can put in a quick fix. I think adding a child element that handled the protection key would be too much of a stretch. There is no digest-algorithm URI for PBKDF2 that works for this. I looked before when digging into the encryption options for ODF 1.2. -----Original Message----- From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com] Sent: Saturday, October 30, 2010 19:29 To: dennis.hamilton@acm.org; 'ODF TC List' Subject: RE: [office] The problem of visible hashes for protection keys Just specifying a digest algorithm is a fairly major flaw. I believe that xml-enc has a way to express a real KDF. One aspect of this that has to be done is to not only specify the digest algorithm, but also the iteration count, so that future versions can increase the iteration count, and older versions can still consume it. At the very least, you need something along these lines: <PBKDF2-digest> <DigestValue Algorithm="URI">base64 of hash</DigestValue> <IterationCount>100000</IterationCount> <SaltValue>base64 of salt</SaltValue> <PBKDF2-digest> Where recommended Algorithm is sha-256, Iteration count is 100k, salt is 16 bytes of random data. I do not know if there's an algorithm URI for PBKDF2, but seems like there ought to be. While I recognize that it is late in the process, due to the severity of this flaw, I think it ought to get fixed for 1.2. If it was not actually defined as part of the 1.1 standard, let's define it as something solid that we don't have to change again later. ________________________________________ From: Dennis E. Hamilton [dennis.hamilton@acm.org] Sent: Saturday, October 30, 2010 6:19 PM To: David LeBlanc; 'ODF TC List' Subject: RE: [office] The problem of visible hashes for protection keys There is a mistake in the previous note. There is a <text:protection-key-digest-algorithm> option for <text:object-index>. I double-checked the schema and rechecked ODF 1.2 CD05, and it is indeed there. - Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] Sent: Saturday, October 30, 2010 17:46 To: 'David LeBlanc'; 'ODF TC List' Subject: RE: [office] The problem of visible hashes for protection keys Nice analysis. Thanks David, Here are the places in ODF 1.1, with the attribute always storing a key-verification hash (now documented in ODF 1.2 as being SHA-1): 4.4.1 Section Attributes, Protected Section subsection, text:protection-key attribute 8.1.1 Table Element, Protected subsection, table:protection-key attribute 8.5.1 Document Protection, table:protection-key attribute [applies to spreadsheets] By virtue of sharing the sectionAttr RNG pattern defined in 4.4.1, protection keys are also allowed on the following elements: 7.3.2 <text:index-title>, 7.3 <text:table-of-content>, 7.4 <text:illustration-index>, 7.5 <text:table-index>, 7.6 <text:object-index>, 7.7 <text:user-index>, 7.8 <text:alphabetical-index>, and 7.9 <text:bibliography>. In ODF 1.2, the additional attributes table:protection-key-digest-algorithm and text:protection-key-digest-algorithm are added to go with the corresponding table:protection-key and text:protection-key occurrences, except it is missing for <text:object-index>. The default is SHA1 and ODF 1.2 consumers are required to support SHA256 also. The digest algorithms are identified by IRI, and new ones can be added, but the explanation for 19.700 and 19.853 *:protection-key-digest-algorithm is a little strange. I will turn in a JIRA issue on these and the omission if there are none already. - Dennis -----Original Message----- From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com] Sent: Saturday, October 30, 2010 16:20 To: dennis.hamilton@acm.org; 'ODF TC List' Subject: RE: [office] The problem of visible hashes for protection keys [ ... ] My recommendation is to use a real key derivation function to create a password verifier. It can be a bit of a problem to deal with versioning - if you change this, then an older version of the software obviously cannot verify the password. However, due to the severity of disclosing passwords, I'd tend to recommend against implementing a feature that exposes passwords in that manner. Just how widespread is this past usage? I do not recall seeing it in the v1.1 spec, but I may have missed it. If this is something new to this version, I'd strongly recommend doing it right, even if there are existing implementations. [ ... ] --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]