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.

2.15.1.28 [p1158, 13...]

te

Proposed Disposition of DIS 29500 Comment GB-0220 (Modified: 2008-01-03) Agreed; the following changes will be made to make this assumption explicit in each algorithm: Part 4, §2.15.1.28, page 1,158, line 15: First, the UTF-16 encoded password shall be hashed using the following algorithm . The following steps assume that all words are unsigned, the word size is two bytes, and that bit-level SHL/SHR 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: BR-0006 , CL-0091 , CO-0098 , CZ-0053 , DE-0088 , GH-0009 , GR-0027 , IN-0075 , IR-0013 , MY-0021 , PT-0039 , US-0052 , UY-0017 , VE-0018