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

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

<orcmid /> Comments edited in-line:

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of David LeBlanc
Sent: Wednesday, June 13, 2012 18:51
To: dennis.hamilton@acm.org; office@lists.oasis-open.org
Subject: RE: [office] [OASIS Issue Tracker] Commented: (OFFICE-3703) Proposal: ODF 1.3 Protection-Key Enhancements

[ ... ]

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.

<orcmid>
Another way to look at it is the first byte is the identifier of a spin count and the remaining 19 bytes are the cryptographically-random salt.  There is some entropy in the first byte, depending on the range that the producer finds tolerable.  I pushed it through with the salt because someone altering the spin count will break the key generation in two ways.  The single byte case makes it easier to deal with filtering out outrageous and trivial values too, and I specified some shoulds about that.  Not attached to it.  That is all I had in mind.  I think this value will last a long time.  The minimum spin, F(26) is just  121,393, and I could lower the floor to F(24) to allow 46368 as a minimum.  The largest spin is F(26+255) and I'm too lazy to compute it.  It probably won't ever be produced in a legitimate SHA1DK generation.
</orcmid>
 
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. 

<orcmid>
I wish I'd thought of it too [;<).  I got it from a few mentions in posts that were analyzing the LinkedIn exploit and talking about things that would have limited the damage of all those leaked SHA1 hashes.
</orcmid>

[ ... ]