On Fri, Mar 25, 2016 at 3:26 PM David Benjamin <david...@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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev