[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=20170#action_20170 ]
Dennis Hamilton commented on OFFICE-2722:
-----------------------------------------
David,
Yes, this encryption has been around since ODF 1.0 and it is implemented in at least OO.o as long as I have been paying attention. This is essentially the default encryption level. I don't know that anyone has used any additional encryption methods, because that is all new in ODF 1.2 and mostly optional. Blowfish (8-bit) CFB is the default still.
With regard to the interdependence of compressed-plaintext size being the same as the ciphertext size, here is a bit more on why the uncompressed plaintext size is retained in the manifest for an encrypted file:
The reason the uncompressed size is held onto in the manifest is that it was removed from a field of the Zip directory block for the file when the ciphertext is put in place of the compressed plaintext and is identified as uncompressed (so the uncompressed and compressed sizes are set to be the same when the block holds the ciphertext). (That's another reason they are expected to be the same size, it seems.)
I think the uncompressed-plaintext size value is retained in case decryption involves stuffing the plaintext compressed file back in place and then restoring the directory block to be the same as it was without the encryption.
I don't know that it actually happens that way, but that seems to be the rationale for the provision.
Since the specification is silent about this, apart from requiring the uncompressed plaintext size to be included in the manifest for an encrypted file, this may have become a craft practice: We keep doing it because we don't know what will break if we don't [;<).
> 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]