[Date Prev][Date Next]
Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
- From: firstname.lastname@example.org
- Date: Mon, 31 Aug 2015 17:54:39 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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
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?
If you don't, please hint me to some code that allows me to check and fix my