Subject: RE: Encryption proposal for ODF1.2?
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 126.96.36.199-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: email@example.com; 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.