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] RE: Encryption proposal for ODF1.2?


Hi David,

great to hear that you make progress here :)

Wrt question 1: I don't have a strong opinion on this.
On one side I think it should be in manifest, because the package should
look the same like other ODF packages, but on the other side this is a
special case, and we also don't have content.xml.
IIRC we have new elements for encryption in the manifest in ODF 1.2
anyway, to allow different algorithms which we didn't have before.

For questions 2: I guess we wouldn't make use of such a feature in OOo
and simply encrypt/decrypt the whole ODF stream, but as long as this is
still supported it's fine for me to add this chunk feature.

For questions 3: I hope somebody who understands more from encryption
implementations will comment on this ;)

Best,
Malte.


David LeBlanc wrote, On 06/30/10 18:45:
> Yes, I'm making progress on this. I've come up with an XML schema to represent the encryption information needed, worked on the cryptographic details with the dev who did our Office encryption and one member of our crypto board. I want to get it into a broader crypto board review this next week. I'm going to be on vacation the next 2 work days, and Monday is a holiday for the US, so I can get back to it on Tuesday.
> 
> I've also given Dennis an initial draft to get his opinions, and some questions have come up which could be discussed here.
> 
> 1) What is the structure of the zip file? That is, what's the naming conventions? We think that putting the encryption information into a file within META-INF would be a good approach, and keeping it out of the manifest would help implementations to not get confused by new elements that don't have a parser. Tentative proposal would be encryption_info.xml within META-INF, and encrypted_data.bin as the stored binary data file contained the actual encrypted stream.
> 
> 2) We have a method in MSO where we encrypt the inner zip in 4096 byte chunks*, where the initialization vector is reset with each chunk. This allows random access, at least to the memory page level, and prevents the need for either a clear-text temp file, or having to deal with the messy problem of dropping a temp file that is itself encrypted. Within each chunk, we use cipher chaining modes. Dennis has pointed out that there would be a possibility of a known-plaintext at the end of the zip stream, but because the chunk size doesn't fall on any natural zip boundaries, we think this is unlikely. I feel like this is aspect of the design really needs some feedback and discussion. One provision I'd thought of was that if the chunk size were a magic number, such as 0, then it would indicate that the entire stream should be encrypted without chunks. What are your thoughts on this?
> 
> 3) I'd propose restricting the cipher chaining modes to CBC and CFB, with CBC preferred. We will be requiring an HMAC on the data stream, so this makes the authenticated chaining modes redundant. Authenticated chaining modes take quite a few parameters, and are difficult to express in a file format. Out of the non-authenticated chaining modes, we have CBC and CFB available in the Windows crypto libraries, and I'd prefer to support something I have available. I'm not familiar with the libraries available on UNIX/Linux/MacOS, but I'd assume these 2 basic modes would be available there. Note that I've provided an any element for all of the crypto algorithms, so an implementer could support whatever they liked, but these two would be defined. CBC should be the preferred mechanism, as the performance of CBC is much better than CFB. Again, I'd like comments and feedback on this, as there may be issues I'm not yet considering.
> 
> * The exact approach is documented in MS-OFFCRYPTO, Agile Encryption sections 2.3.4.10-12. Note that I'm not proposing precisely the same mechanism, but the general approach is similar. This proposal also gets benefit of some very minor hindsight.
> ________________________________________
> From: Malte.Timmermann@Sun.COM [Malte.Timmermann@Sun.COM]
> Sent: Wednesday, June 30, 2010 3:11 AM
> To: office@lists.oasis-open.org; David LeBlanc
> Subject: Encryption proposal for ODF1.2?
> 
> Hi David,
> 
> IIRC, you wanted to submit an ODF encryption proposal where we would use
> a similar approach like in OOXML (putting the document in an encrypted
> archive, wrapped into an ODF package containing needed information about
> the encryption algorithm used).
> 
> With this encryption approach, we probably don't need to further discuss
> how to encrypt document signatures, because in such an encrypted
> document they would automatically be encrypted.
> 
> Any time line for your proposal?
> 
> (Hope I didn't simply miss it in all the mails currently coming through
> OASIS mailing lists...)
> 
> Best,
> Malte.
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 


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