[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
All excellent points, of course. But in 12 hours now one will remember or find what you said, unless this was entered into JIRA. -Rob "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 10/30/2010 10:45:51 PM: > > 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 > > > --------------------------------------------------------------------- > 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]