OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Re: [office] What to do about encryption?

    Posted 05-11-2010 15:45
    David LeBlanc wrote, On 05/11/10 17:14:
    > Malte said:
    > 
    >> Last but not least one goal/wish was to stay quite compatible with ODF
    >> 1.1 - but the new encryption approach would be completely incompatible
    >> with every existing implementation.
    
    > 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...
    
    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.
    For ODF, there are multiple implementations, and I guess at least 3
    implement encryption.
    
    > So if you're going to break compatability, then let's go ahead and do
    > that while fixing everything you know that should be fixed.
    
    I agree that we should fix everything in one step.
    And we should also try to get it right in one step.
    That's why I suggest to not do it in the long awaited ODF 1.2, but to
    take more time to investigate into everything more deeply.
    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.
    
    > It is also up to the implementer which approach to use by default. For
    > example, I am at the start of a development cycle. If the other
    > implementers all support the new encryption, then I would make that a
    > default, but I'd still have to warn that MS Office 2007 cannot read it,
    > unless I had some way to update that version.
    
    I guess you have the MSO2007 issue anyway, because it currently don't
    support any ODF encryption, AFAIK.
    
    
    > I agree that we should design the encryption carefully, but I'm not
    > completely sure of the schedule and will refrain from commenting on
    > that. I will say that I would be happier about implementing something
    > that is part of the standard, unless perhaps we have some way to make a
    > working group that can come to an agreement.
    
    Implementing the old ODF encryption in MSO (at least for importing ODF)
    could be a good idea anyway, for interop reasons.
    
    
    > I also agree that many of the flaws I listed are minor, some extremely
    > so (e.g., the iteration count for the KDF, which is easily corrected),
    > 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....
    
    Malte.
    
    


  • 2.  RE: [office] What to do about encryption?

    Posted 05-11-2010 17: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.