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.
-Krishna
