Re: [office] What to do about encryption?

[Malte Timmermann <Malte.Timmermann@Sun.COM>]

Hi David,

thanks for all your comments and for the MSO insights :)

Of course it can't do any harm to start working on the new specification
asap, and then see how to deal with it wrt introduction into the ODF
specification and it's time line.

Good to know that your 'crypto board' would probably review the
specification too.

Best,
Malte.



David LeBlanc wrote, On 05/11/10 19:43:
> Malte said:
> 
>>> Yes, but that's unfortunately the nature of encryption changes. If you 
>>> change the slightest thing, you introduce incompatabilities. This is 
>>> why we shipped the new encryption that was to go into 2010 in the 2007 SP2.
> 
>> Ah - that explains why the situation was different than what I remembered.
>> My memory was that MSO2007 would store something that is not a zip container anymore. So it changed with SP2...
> 
> Unfortunately not - the outer container is still an OLE structured storage, like an older binary document file. I wish we had been able to change the outer container at the time. It would remove a 2GB size limit that OLE files have.
> 
> As you may have noticed, the encryption for OOXML files is not terrible, in contrast to the RC4 encryption on older files. However, it wasn't implemented by crypto specialists, and didn't get benefit of review by our internal team of cryptographers. It had several flaws, several of which are in common with ODF:
> 
> 1) No HMAC
> 2) Encrypt known plain-text
> 3) ECB mode, no chaining mode
> 4) Lack of an intermediate key
> 5) Symmetric algorithm is not flexible
> 6) KDF spin count not configurable (though it is high, at 50,000)
> 
> We needed to fix these, and that's what's the new version is designed to fix. This is partially why I'm able to give a detailed proposal - we just went through a detailed re-design and associated reviews for OOXML, and can help this standard avoid making some of the same mistakes we have made in the past.
> 
>> But you are in the comfortable position that there is no other implementation for (encrypted) OOXML files except MSO, where you have full control over older and newer versions, and what you want to update.
> 
> To some extent, but I also have the reality that at any given time most of my customers are using version N-2; backwards compatibility is always a big concern. And it is all fully documented and the documentation is available well before release. If you would like to implement it, you should have all the information you need, and once you do, then we're all in the same boat. As an aside, if you do need any assistance in implementing the encryption, we will be happy to help. I believe that what we have now is very robust, and other than the outer container, I don't think we'll be changing encryption substantially any time soon.
> 
>> For ODF, there are multiple implementations, and I guess at least 3 implement encryption.
> 
> True, and if I get my preference, there will be 4.
> 
>> It also would be helpful to start with an actual implementation in parallel, to experience any issues early.
>> I am not sure if it's a good idea to simply publish anything that nobody tried out with a real implementation.
> 
> These are very good points. We're in a stage in our cycle where we can make prototypes, so maybe we can work together on this.
> 
>> I guess you have the MSO2007 issue anyway, because it currently don't support any ODF encryption, AFAIK.
> 
> Some of that is because of scheduling issues. We needed to work quickly to get ODF support into 2007 SP2, and some things ended up not getting done. The other part of it is because the Windows OS does not support Blowfish, and our crypto board is very reluctant to allow anyone to ship encryption algorithms that were not implemented by the core crypto team. A third problem is that we cannot meet any government agency encryption standard and still emit a compliant document, though being able to use alternate algorithms will certainly help the last 2 problems.
> 
> As an aside, I think by MSO, you mean 'Microsoft Office' - ironically, most of the encryption, etc, goes into mso.dll, and that's the area of code where my group spends most of its time.
> 
>> Implementing the old ODF encryption in MSO (at least for importing ODF) could be a good idea anyway, for interop reasons.
> 
> I agree, but I have to sort out how to get Blowfish. We do have some code for it, but there are hoops to jump through to make it part of our app.
> 
>>> but now that we've come upon the issue that a signed file cannot be 
>>> encrypted, and an encrypted, then signed file can never be decrypted 
>>> without breaking the signature, I think that's a fairly major issue.
> 
>> Well, we don't have an ideal situation, but it's still not clear whether or not the use cases really can't be done with minor modifications/explanations in the current specification....
> 
> I am not so sure - if the encryption information must be in the manifest, then it is not solvable, except by adding an outer layer. I also see it as an inconvenience if we end up needing to support 3 approaches (legacy, 1.2, and the current proposal). I'd prefer to deal with 2 if possible.
> 
> I'd propose that we first figure out how we'd like to do this, then see about some prototypes, and we can sort out the schedule as we go along. Also, I have an internal requirement that when I ship a cryptographic implementation that it be reviewed by our 'crypto board', which consists largely of cryptographers who work for Microsoft Research. I will leverage that resource to get our proposal reviewed, and that will help ensure that the approach is robust.
> 
>