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.

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.

03/02/29 te

1916(1923)

Proposed Disposition of DIS 29500 Comment CO-0144 (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 , DE-0092 , FR-0342 , GB-0293 , GR-0077 , IR-0048 , PT-0094 , US-0139 , VE-0055