[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2722) ODF 1.2 Part 3 3.4.1Plaintext and Ciphertext Same Size?
[ http://tools.oasis-open.org/issues/browse/OFFICE-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21999#action_21999 ]
Michael Brauer commented on OFFICE-2722:
----------------------------------------
There are three streams involved:
(1)-plain stream
(2)-compressed stream
(3)-encrypted stream
The size of the (2) is not necessarily the same as the size of the (3), although it will be usually the case. Actually this size is only necessary if the algorithm that is used to decrypt the (3) needs to know the target size. The mentioned example with the block-encryption does not look nice without this info. But that seems to be a special case, when the size of (2) is necessary, and thus should be probably stored in the algorithm-related part of data.
The size of (1) is not really necessary also, at it is correctly mentioned, but it is very comfortable to have this information while working with the stream. Thus this information is stored in the manifest.xml, to allow to get to the stream size without decryption/decompression.
The mentioned in "PS:" CRC is intended to detect the information loss in case of zip-file corruption, it does it well for encrypted streams. Since an encrypted stream is stored in the zip-file directly ( "stored" method ), the CRC of (3) is calculated. The ODF-specification unambiguously defines this behavior by requiring usage of "stored" method for storing of (3) in the zip-file.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]