>> 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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
