For x86-64, this seems to be the bug:
$ git diff
diff --git a/crypto/poly1305/asm/poly1305-x86_64.pl b/crypto/poly1305/asm/
poly1305-x86_64.pl
index 3c810c5..bc14ed1 100755
--- a/crypto/poly1305/asm/poly1305-x86_64.pl
+++ b/crypto/poly1305/asm/poly1305-x86_64.pl
@@ -97,6 +97,7 @@ $code.=<<___;
add $d3,%rax
add %rax,$h0
adc \$0,$h1
+ adc \$0,$h2
___
}
In the final reduction, $h1 is all ones, so there is one more carry to
propagate. Though $h2 can then overflow its two bits, I think? I expect
that and the cleared bits of r mean the imulqs in poly1305_iteration are
still safe, so we can pick up that slack in poly1305_emit, but I'm not sure
about all the complex switching back and forth in the SIMD codepaths. Does
__poly1305_block need to follow up with one more reduction?
I seem to be able to reproduce failures on all four of {32,64}-bit
{arm,x86}. I'm guessing the other three have similar issues, but I haven't
looked at them yet.
David
On Fri, Mar 25, 2016 at 1:25 PM Andy Polyakov via RT <r...@openssl.org> wrote:
> > Attached is an updated version of the test with an additional test
> > vector. This one happens on 64 bit and not on 32 bit.
>
> Got it. It will take some time to perform cross-checks. Thanks!
>
>
>
> --
> 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
>
--
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
