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

[David LeBlanc <dleblanc@exchange.microsoft.com>]

If someone munges the spin count, then you won't derive the password, because the number of iterations must match, or you get drastically different output. So you already have that property without doing anything special. I'd recommend doing something like so:

 

unsigned long cSpin;byte string in base64 - salt Note that a base64 string carries the number of bytes of salt with it, so we don't need an additional size parameter for the structure. As to what spin counts are too big, too small and just right, that would be an implementer detail. I do not want to guess what might work 10 years down the road. We doubled the number of iterations in just 3 years. I'm pretty sure 4 billion iterations ought to be enough for anyone, but make it a size_t if you want. You could set a floor at some reasonable value to prevent luring attacks - say 10,000. You don't need it to break more than one way. One is fine. A single flipped bit in the salt will result in a completely different output. No such thing as a little broken - it is either dead on, or it is completely off. Something else to avoid is any dependency on hash algorithm or size of hash. Which means that you should have some sort of identifier for which hash got used. For example, the Russians like to use GOST, not SHA. The Chinese like to do their own thing, too. The way I have solved this in the past is to have a string that defines the hash, along with certain reserved values, like 'sha1', 'sha256', etc. I'd even reserve some strings you don't plan on using, like perhaps RIPE-MD. So we then map these reserved values to standards such that everyone knows what they are talking about, and then we say that implementers MUST support say sha256, MAY support the rest of them, and MAY use implementation-defined strings. This also implies that it would be a good idea to come up with some more generic name for the approach, and not call it SHA-something. Note that the hash size problem is solved the same way as the salt - store it as a base64 string, and the string becomes its own definition of size. Another note - for this sort of application, sha-1 is really just fine, but some of the more recent crypto standards (NIST, and EU equivalents) frown on anything less than sha-256. If I want to do something with sha-1 at Microsoft, it needs an exception from the crypto board. For that reason, I'd tend to encourage the default to be sha-256. You'll have an easier time with the crypto standards people. Not that it will be very much more effective. I would just keep this simple - take the password, concatenate the context onto it, and then feed it to PBKDF2. Then you just need to find a way to store the salt, spin count, context, and algorithm ID (and obviously the output). The closer you stick to just putting as small a layer as possible on top of PBKDF2, the easier it is to document. I still want to take a closer look at your other one, but not this evening. IMHO, YMMV.









________________________________________



From: Dennis E. Hamilton



Sent: Wednesday, June 13, 2012 7:17:18 PM



To: David LeBlanc; office@lists.oasis-open.org



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







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







[ ... ]