On 10/24/08 20:05, Krishna Yenduri wrote: > Ferenc Rakoczi wrote: >> Krishna Yenduri wrote: >> >>> Hai-May, >>> >>> I have an update to an earlier comment and a new comment. >>> >>> Regards, >>> -Krishna >>> >>> >>>> Hai-May Chao wrote: >>>> >>>>> I updated my webrev with review comments from Dan and Ferenc. >>>>> The updated webrev is at: >>>>> >>>>> http://cr.opensolaris.org/~haimay/CR6703956-v1/ >>>>> >>>> ... >>>> >>>> KY-1 T3 lines 33-34, 106, 135 >>>> fips_add160() expects val1 and val2 to be in big-endian >>>> format. I assume the correctness of the operation depends >>>> on that. >>>> >>>> If so, you need to do some conversion for little-endian >>>> case, on lines 106 and 135. >>>> >>> Thinking a bit further, I don't see the need for these arguments >>> to be in big-endian format since it does not matter whether >>> a 160-bit random number is reversed for the purpose of a PRNG. >>> Recommend just fixing the comment. >>> >>> >> I think that code is good as is, including the comment. The machine >> endianness problem is solved by treating the 160-bit value as an >> array of 5 uint32_t values (not a byte array) > > The for loop in the following code in fips_add160() - > > 51 for (i = 4; i >= 0; --i) { > 52 partialsum = val1[i] + (complement_val2 ? ~val2[i] > : val2[i]) + > 53 carry; > > > is counting down to treat it as big endian for the purpose of the > addition. > I believe the comment on line 33 was referring to that. The for loop > can count up > if we want to add them in little endian order. The result can be > different > in that case. But, the order does not matter here since this is a PRNG. The comment talks about how the 160-bit numbers are represented and it explicitly states "native byte order within words" which means there is no machine endianness problem. All the computations that deal with these 160-bit numbers obey this representation, this is why there is no need to change anything depending on whether you run on x86 or sparc. The argument "order does not matter here since this is a PRNG" comes into play when (after the computation) we provide a random bit (well, byte)-string and we don't use any conversion from this 160-bit number representation to the bit-string representation. When doing correctness testing using known answer tests provided by someone in bit-string representation, we do need to convert, and that conversion will be different on little and big endian machines, but only in the order of the bytes within the words. The for loop you quote will not change.
Ferenc
