[openssl-dev] [openssl.org #4439] poly1305-x86.pl produces incorrect output
Andy Polyakov via RT
rt at openssl.org
Tue Mar 29 14:50:33 UTC 2016
>>> No, it doesn't depend on call pattern. Please confirm that attached
>>> patch solves the problem. Thanks.
>> (Right, sorry, I meant that the test vectors I have seem to only with
>> their corresponding call patterns.)
And I meant that I observed failure pattern other than suggested. Never
>> The patch works on my end, and naively comparing random inputs against a
>> reference implementation doesn't reveal any other issues. Thanks for fixing
>> it so quickly!
> Andy, there appears to be a typo in the patch. It says defined(extra)
> rather than defined($extra). It was evaluating a bare word and always using
> The $extra version seems to work too, but may I suggest adding some
> comments here?
I'll add comment (and elaborate on below questions) at later point, more
specifically after RT#4483 is resolved.
> If I'm understanding correctly, the paddd vs paddq decision is about
> whether the sum fits in 2^32 rather than needing the full 2^64, right? And
> you use paddd preferentially over paddq because paddq is slow on Atom? This
> isn't very clear from "because paddq is "broken" on Atom". It's also no
> longer next to where $paddx is computed.
> Moreover, it seems lazy_reduction conditioning on $extra isn't because
> $extra is in itself significant, but because $extra being set means we are
> following the tail logic and a horizontal addition, so the bounds don't
> hold anymore? This could do with a clear comment.
> Finally, where paddd is used, it's probably worth a comment for why the
> bounds hold and under what assumptions. I haven't been able to trace
> through them myself (based on the paper, it looks like the result of the h4
> -> h0 carry after the horizontal addition should be bound by 2^26 + 2^26 *
> 5 * 2 * 5 = 2^26 * 51, but looking in a debugger, it's larger, so clearly
> I'm missing something), so I can't suggest any particular text.
> PS: By the way, this typo would have been caught by use strict. Have you
> all considered moving perlasm to be use strict clean?
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4439
Please log in as guest with password guest if prompted
More information about the openssl-dev