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

[David Benjamin via RT]

On Fri, Mar 25, 2016 at 3:26 PM David Benjamin <davidben at google.com> wrote:

> 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?

David

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