[OASIS Issue Tracker] Commented: (OFFICE-2722) ODF 1.2 Part 3 3.4.1Plaintext and Ciphertext Same Size?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20169#action_20169 ] 

Dennis Hamilton commented on OFFICE-2722:
-----------------------------------------

David LeBlanc commented today, <http://lists.oasis-open.org/archives/office/201008/msg00230.html>:

I think it practically depends on what you want to do - saving the size of the uncompressed data isn't an especially useful thing to do, but if you now start requiring more information, then you'll break any existing implementation.

I think I'd tend to make as minor a set of changes to the existing encryption approach as possible; you've clearly identified it is broken in a number of ways, and completely incompatible with signatures, as well as violating a number of NIST requirements and recommendations. 

What we should be putting our energy into is refining a better, more robust approach, but we also know this can't practically be done (and probably shouldn't - need to allow a fair bit of review time) in time for 1.2.

On a practical basis, I'm not sure that missing the size information is really deadly. Let's assume that the crypt-text has been truncated or extended. We then decrypt it, and either end up with an invalid compressed stream, or a compressed stream with trailing information it won't use. The invalid stream should get rejected as an error, and the trailing information would be benign.

So the existing spec is not ideal, but I'm not sure that fixing it really improves matters. Do we have any existing implementations that a change would break? Microsoft Office won't encrypt ODF files now, so we have no vested interest - I don't know about the other vendors.


> ODF 1.2 Part 3 3.4.1 Plaintext and Ciphertext Same Size?
> --------------------------------------------------------
>
>                 Key: OFFICE-2722
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2722
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging, Part 3 (Packages), Security
>    Affects Versions: ODF 1.2 CD 05
>         Environment: This issue applies specifically to section 3.4.1 of ODF 1.2 Part 3 CD01-rev08 and the ODF 1.2 CD05 Part 3 approved form.  The question also applies to ODF 1.0/1.1/IIS 26300. 
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
>
>
> In the third paragraph of section 3.4.1 on General Encryption provisions, it is stated that the uncompressed file size of the deflated file data (the plaintext) is saved in the corresponding <manifest:file-entry> manifest:size attribute value.  The deflated file data is replaced by the encryption (ciphertext) of the deflated file data, the entry is changed to STORED and the size of the encrypted file is then carried in those places where the file's real size value is carried.
> 1. Why is flagging as STORED asserted for the Zipped file's central directory entry and no other place, although the ciphertext size is placed in all applicable places?
> 2. There is no indication of how the size of the plaintext deflated file is to be recovered.  Is it to be assumed that the ciphertext size is the same as the size of the plaintext deflated size, so there is no need to recover it separately?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira