[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=22762#action_22762 ] Dennis Hamilton commented on OFFICE-2722: ----------------------------------------- The problem is that CBC requires padding, for example. If the decrypted padded-plaintext is in a form where the padding can be removed correctly, that works. That will then be the original deflated form of the file, and inflating is assured to work correctly. The cases we have with AES-128-CBC, for example., as defined in [xmlenc-core] always have the ciphertext be larger than the plaintext (DEFLATEd package file). The IV is the first block of the ciphertext. The plaintext is padded with from 1 to 16 bytes to make it be a multiple of 16 bytes. However, the IV is removed as part of the decryption process and the padding in the plaintext is always accurately removable, leaving a plaintext that is exactly the right size. (Oddly, the padding has predictable 0 bytes in it and random bytes for all but the last padding byte would have been more fun. I suppose this would provide a covert channel though, so forget that. The padding should be checked for 0 in all but the last padding byte in any solidly-implemented decryption method) 2(b) is simply a general statement of a requirement that [xmlenc-core] AES-128-CBC does satisfy. It is provided in case there are other kinds of padding and addition of information that an encryption algorithm might introduce. It might be that 2(b) could be in a note that simply reminds users of various encryption methods that this must be handled somehow. I'm not sure that it can be inferred very easily from the separate information, though, and I worry about requiring mind-reading. > 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