[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements

Peter Marschall wrote:
> Hi,
> On Sunday, 30. August 2015 23:58:09 Howard Chu wrote:
>>> Please note the run index i changed direction, which causes different
>>> results because of  >>=.
>>> In my tests [double checked before sending this mail] on an amd64 [little-
>>> endian architecture], the patched version converts 0x3837363534333231 to
>>> - "87654321"	in the !WORDS_BIGENDIAN case [unchanged]
>>> - "12345678"	in the WORDS_BIGENDIAN case
>>> [using the fact that  0x3N = "N"  for 0 <= N <=9]
>>> To me that looks correct.
>>> What issues did you see exactly?
>> That is exactly wrong. Given any integer input the string should be
>> identical regardless of endianness. It should be "87654321" in both cases.
>> With your patch, hashes will be incompatible between different machine
>> architectures.
> Please read my mail again!
> I tested the WORDS_BIGENDIAN case on a *little-endian* architecture using the
> same data as the !WORDS_BIGENDIAN case.
> In that case [i.e. testing on the "wrong-endian" architecture] the result *is
> expected* to come out in reversed order.
> Otherwise it would end-up in wrong order on the "right-endian" architecture.
> Do you agree?

The point is that your patch *always* reverses the order of the bytes. On a 
big-endian machine the code should be a no-op.
> If you don't, please hint me to some code that allows me to check and fix my
> code.
> Best
> Peter

   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/