OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office] [OASIS Issue Tracker] Commented: (OFFICE-3703) Proposal: ODF 1.3 Protection-Key Enhancements

While I Am Not A Lawyer, and you should check with one to be completely sure, I suspect that PBKDF2 is not encumbered with patents. It's a very standard way to derive a key from a source with less entropy, and all sorts of things do either exactly that, or something very close. I do know that it is an exported function from the .NET framework.

BTW, hashing algorithms are considered cryptographic algorithms, even if encryption is not involved.

I need to review the proposed AUTHZ160 at greater length. It looks interesting. I have some concerns about usability.

Re-using the salt to do double duty for the spin count isn't something I'd recommend. Salt should be just completely random. A spin count should be as high as you think users can tolerate. FWIW, currently shipping Microsoft Office encryption uses a spin count of 50,000, and it will go higher in the future. This keeps the operation at about 0.25 seconds on a relatively low-powered system, so it is just below what a user will notice. It also seems to do a very adequate job of fending off the password crackers.

I like the idea of hashing in a context. A weakness in using salt is that people make mistakes and re-use it, even though it should always be new and random. Supplying a context helps with that, and also helps to prevent copy and paste into some other area where it shouldn't be used. Not absolute security, but certainly a good move in the right direction. I wish I'd thought of that myself. 

Will try to respond with more inputs tomorrow - 

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Dennis E. Hamilton
Sent: Wednesday, June 13, 2012 5:51 PM
To: office@lists.oasis-open.org
Subject: RE: [office] [OASIS Issue Tracker] Commented: (OFFICE-3703) Proposal: ODF 1.3 Protection-Key Enhancements


I am not clear what claims one should search for,

 1. The proposal does not introduce any cryptographic algorithms, since encryption and decryption are not involved.

 2. The use of SHA1, PBKDF2 with HMAC-SHA-1, and assumption that cryptographically-random salts are producible is already required in the ODF specification, although not all of them directly for creation of protection-key values.

 3. The only novelties I can think of are 

    3.1 AUTHZ160 use of a non-password-based 160 bit value in places where an SHA1 hash is expected.  This is the same as intentionally using a hash-like value that has no password.  There's nothing about how authentication might be accomplished.  It is not even specified that authentication must be possible.  (Although I sketch one possibility in the proposal, and say more about SHA1DKX in a comment, it is not part of the proposed text for ODF 1.3).

    3.2 SHA1DK derivation of the iteration count from the first byte of the PBKDF2 salt.  This is simply a mathematical technique for using only one byte to select from a list of increasingly large values that has the technical advantage of not growing so fast as 2^n.  This is functionally no different than taking a few fixed bytes from the salt for holding a count value.  SHA1DK is essentially a minor, custom parameterization of PBKDF2 in PKCS#5.  SHA1DK is equivalent to how PBKDF2 is used for password-based key generation in ODF 1.2 Part 3 Package Encryption. 

 4. In the note about SHA1DKX, the further addition of a context value of some kind to make the result dependent on a particular use case is apparently not novel, since I have seen it mentioned several times in the discussions on the Internet about the problems that the LinkedIn hack (so-called) could have been mitigated.
Given that, what should a patent search be looking for?  It would have to be something not already being used in the ODF specification, presumably, as well as perhaps having been considered novel at some previous time and patented then.  

What are your suggestions for patents to search for? 

 - Dennis

PS: Of course, those of us who participate in the production of an ODF 1.3 that has these provisions will be automatically bound under the OASIS IP regime that applies.  I suppose that might inspire the participants with deeper pockets to engage in a patent search to ensure that there is no danger from outside of the obligated participants.

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of OASIS Issues Tracker
Sent: Wednesday, June 13, 2012 16:58
To: office@lists.oasis-open.org
Subject: [office] [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=30615#action_30615 ] 

Andre Rebentisch commented on OFFICE-3703:

Sounds interesting. Prior to inclusion any proposal should be professionally checked for third party patent infringements. Applied cryptography is mined territory and in this case overriding third party patents would fundamentally break interoperability of implementations. I am aware that often the prospect of US triple damages is used to avoid patent searches by industry but here the standards has to be kept clean.
(Visible to TC List role)
> 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


To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org

To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]