OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  What to do about encryption?

    Posted 05-10-2010 21:46 
    We also need to do something with encryption, as well - the existing approach has a number of problems.

From a mail I sent Malte earlier this morning - 

1) You could replace an encrypted file with one that is not (interesting to see this in the blog post - I came on this Friday independently)
2) There's a known plain-text problem, where the encrypted data would be predictable in many files.
3) The integrity check covers only 1024 bytes.
3a) Giving a hash of the unencrypted data externally to the encrypted area may not be a fatal flaw, but it does give out information that isn't required.
4) We tell people the size of the plain text
5) Information leaks WRT file names - I suspect embedded files may leak interesting info here.
6) Signatures and encryption do not play well together.
7) No provision for an independent password verifier and integrity check
8) Low default spin count on the KDF
9) Telling people to reduce randomness by initializing on time - shouldn't be in a spec - just use as good a random number as you can get - this differs by OS and version.
10) There is no intermediate key, so no possibility of doing an escrow key, or allowing public key encryption on more than one key.

How to fix it:

Use an outer archive to contain the inner archive. The outer archive is itself a valid ODF file, and contains:

1) Encryption information (you could put this in the metadata as you do now, or could make a separate file)
2) Benign metadata (optional)
3) Dummy files (optional)

Integrity check -
1) Generate random salt, at least 1 block size, default = 16 bytes
2) Pre-pend the salt to the inner archive to be encrypted. This removes known plain-text attack when in any chaining mode other than ECB.
3) Encrypt
4) Calculate HMAC over crypt-text

Attacker cannot re-create HMAC without decryption.

Creating a key from a password - 
1) Generate random salt, configurable amount, 16 bytes = default
2) use RFC2898 approach as you do now
3) Configurable spin count, as in current spec, but I'd increase default to at least 50,000. [NOTE: Current Microsoft Office uses 100,000, Office 2007 does 50,000, Elcomsoft considers it a worthy challenge]

Password verification - 

Ideally should be independent of integrity check. The way that MS Office has done this seems to be a good way, but I am sure other approaches are valid:

1) Generate 16 bytes random data.
2) Take hash of random data
3) Encrypt and store both of these

Intermediate key -
Password encryptor is used only to encrypt intermediate key, intermediate key is used for decrypting the inner archive.

The above approach solves all of the issues I listed, and there is no reason one could not add a signature to the outer archive if that was desired. I still think this isn't a mainstream scenario, but it is there if wanted.

Some nuances to consider - 

When defining an algorithm, we need to not just define key length and chaining mode, but also padding mode. I would tend to do each one with individual XML elements, and not combine them as in the current approach.

I'd also suggest that since this approach is very different than the previous approach, that it would also be a good time to make a break from requiring Blowfish, which doesn't meet any government criteria I'm aware of. I'd suggest going with AES-128 as a minimum.

Let's discuss - if this seems like a good overall approach, I can try to turn it into a more detailed proposal.


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

    Posted 05-11-2010 16:58 
    The intriguing use of an outer archive is that it can be used to contain any
kind of inner archive, so it is a valuable provision in general packaging.  

It also occurred to me that this could be used to encrypt standalone XML
documents, including the single-XML-file OpenDocument format.  It is
relatively easy to sign that document using XML Dsig already, although we
don't address that prospect in the ODF specification.

Just thinking out loud.


  - Dennis
  - - - - - - - - - - - - -
   Standards are arbitrary solutions to recurring problems (R. W. Bemer)
   Although not by becoming the recurring problem (orcmid).
  When you find yourself in a hole, stop digging.


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Summary 2010-05-11 of OpenFormula meeting

    Posted 05-11-2010 17:07 
    Summary 2010-05-11 of OpenFormula meeting

(As always, please reply-all with corrections.)

Attendees:
David A. Wheeler
Andreas Guelzow
Dennis Hamilton
Rob Weir
Patrick Durusau
Eike Rathke
Eric Patterson
Michael B.

Note: For our current status, see the dashboard:
http://tools.oasis-open.org/issues/secure/Dashboard.jspa?selectPageId=10056

We discuss the current specification status,
OFFICE-2672 (character set support),
and OFFICE-2680 (Part 1 / Part 2 connection).
Wheeler wants to plan on meeting next week; we may be able to cancel it,
but it's easier to cancel meetings than schedule them.

===================


Topic: Current status document
Rob Weir: Yesterday TC call - we reviewed the status of defects.
There's never 0, but we've reached a low number and a comfort level, so
we'll turn it into a single set of all 3, to release as a single 3-part
proposed committee draft.  That CD, if approved, would have a
60-day review period.

There are some security-related concerns about digital signature support,
etc., and encryption; we agreed to look at that during the 60-day period.
Final resolutions to OpenFormula are being resolved this week.

Any additional changes made now will be made after the public comment period
unless it's "incredibly urgent" (i.e., causes the CD to fail).
Any changes after a CD need to be change-tracked in some way.
(It may be via a special style.)


Topic: OFFICE-2672 (Internationalized) "Text in OpenFormula"
http://tools.oasis-open.org/issues/browse/OFFICE-2672

Rob: I'd like to limit discussion on the *technical* aspects, and
defer consideration of other matters.

Eric: Not sure what Excel supports.

Dennis: The red flag is that it's specific to ASCII.

646 is a 7-bit code; ASCII is an ANSI standard.
The international standard 646 allows for some substitutions.

PARSING:
Rob: Can we say the syntax of OpenFormula only requires ASCII,
other than strings?
Wheeler: In a sense - You can use &#...; to represent anything.
Dennis: The right name would be "basic Latin".
Wheeler: There's also the names of named expressions.
Rob: Can a formula be parsed with a parser that only accepts basic Latin
 characters, except for strings and names of named expressions?
Wheeler: Essentially yes.  All function names are within
 basic Latin characters, as are operators, etc.  Note that this DIFFERENT
 than the run-time issues.
Dennis: Beware - it's the *characters*, but it's just the
 basic Latin characters.  It's wrapped in XML, anyway, so we
 don't need to talk about encodings.
Michael: Similar to part 1.  The defined terms only use ASCII characters;
 there is no limitation on the characters permitted in data.
 I'd expect to have named expressions that can be *named* and *process*
 other characters.

Wheeler: Spreadsheets generally *display* function names in whatever
language is used, which is not necessarily the same as what is stored.

Eike: You can give function names with arbitrary characters.
Dennis Hamilton: Even if you only have basic Latin characters,
 you can use XML character entities &#...; to do the rest.
Rob: The philosophy has been to be able to implement things in a more
 constrained environment.  E.G., we have not rigidly required
 IEEE 64-bit numbers.
Dennis: I think the issue is that the WAY that we expressed it was
 a red flag (e.g., ASCII).  We shouldn't have said anything.

?: Could just define string as a sequence of Unicode characters,
and drop the second sentence entirely.
Wheeler: What about "UNICHAR(65537)"?
Rob: The code points depend on the character points.

GNUMERIC and OpenOffice.org support arbitrary Unicode characters.
Excel - unknown.

Eric: We should be clear about parsing formulas vs. run-time behavior.
For run-time behavior, it depends on the run-time environment.
Eric: That should be handled somewhere other than 3.2;
instead handle it in the conformance clauses.




Topic: OFFICE-2680 Part 1 / Part 2 connection
http://tools.oasis-open.org/issues/browse/OFFICE-2680
Dennis Hamilton: I have questions about the division of labor.


Rob: I created "identifiers", and mapped into part 1,
using the "identifiers" as common keys.
Then functions can be modified to note the identifiers.
I added "HOST-LOCALE" since several functions depend on that.
Dennis thinks some of them don't belong; if we need to take
any out, we can do that.

Dennis: (See his comments). HOST-REFERENCE-REVOLVER was
intended to be HOST-REFERENCE-RESOLVER.  This
will help stabilize definitions.

Dennis: One thing that is not clear is error values.
Error values may be returned, and we allow the literals
to name values as well as deliver an error back to the host.
There should be more hand-shaking for these.

Michael: I don't see how that involves the specification.

Rob: There's no specification on how these values
are provided to the evaluator (bindings, etc.); no need to do so.


OFFICE-1187 is resolved.

Wheeler: Let's plan on meeting next week.  We may be able to cancel it,
but it's easier to cancel meetings than schedule them.



--- David A. Wheeler


Related Content