[openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

[Andy Polyakov via RT]

>> Right. What I meant is that a fully reduced h has $h2 < 4. Is it possible
>> that $h2, after that adc, ends up at 4, exceeding that bound? If it were,
>> that would require one more reduction.
>>
>> In the non-SIMD paths, I believe this is fine because $r0's and $r1's
>> cleared high bits mean we should have plenty of slack to leave that
>> unreduced. (And indeed its normally not reduced on input from the
>> addition.) Then poly1305_emit's reduction after adding s will resolve
>> things before output. But, in the SIMD paths, __poly1305_blocks is called
>> and then bits are shifted without any reduction. Wouldn't that cause a
>> problem? Or is this situation impossible?
>>
> 
> Pondering this some more, I missed that the base 2^26 representation still
> has six bits extra, so we shouldn't immediately lose that bit. How tolerant
> is the SIMD code to a partially-reduced h? (I haven't puzzled out how it
> works yet.) Is this within its bounds?

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=dc3c5067cd90f3f2159e5d53c57b92730c687d7e
provides background information (and ensures paper-n-pencil boundary
condition on ARM and x86). Ticket is being closed.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted