This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding UTF-16BE UTF-16LE UTF-16 with a BOM (Byte Ordering Mark) The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit.

Proposed change: Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability. Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with.

3.2.29 [p1916, input password encoding ]

te

Proposed Disposition of DIS 29500 Comment GB-0293 (Modified: 2008-01-04) Agreed; any such assumptions should be explicitly stated in the text. The following changes will be made: Part 4, §3.2.29, page 1,916, revisionsPassword attribute, paragraph 1: Specifies the hash of the password required for unlocking revisions in this workbook. The hash is generated from an 8-bit wide character. The input string shall be in UTF-16 format, and these 16-bit Unicode characters must be converted down to 8 bits before the hash is computed, using the following logic: Part 4, §3.2.29, page 1,921, revisionsPassword attribute, paragraph 2 (after the first code block): The resulting value is hashed using the algorithm defined below. This step assumes that all words are unsigned, the word size is two bytes, and that bit-level shift-left/shift-right operations shift in the direction of the highest-order and lowest-order bit, respectively. [Example: 0x61 SHR 1 is 0xC2, as 01100001 shifted one position in the direction of its highest-order bit is 11000010. end example] Similar Comments: CL-0198 , CO-0144 , DE-0092 , FR-0342 , GR-0077 , IR-0048 , PT-0094 , US-0139 , VE-0055