This is the test that I use to sanity-check significant changes to the
package, thus it's probably worth checking it in. Since it's very slow,
it's disabled by default.
(Note that while it stands a good chance of catching errors in 32-bit
implementations, no amount of random testing is going to get useful
coverage for 64-bit implementations. Thus it really is just a sanity
check, despite the long run-time.)
Change-Id: I95b321eec6f3026dafbbc157a7ef35a27e88d247
Reviewed-on: https://go-review.googlesource.com/36566
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Often intermediate results of poly1305 calculations are only reduced to
the range [0, 2^130). These new test vectors exercise the code that
reduces the final output to the range [0, 2^130-5).
This improves the test coverage of CL 35294 and CL 32812.
Change-Id: Ifd2f64d4668c08a396ed81db3e88969a49baf777
Reviewed-on: https://go-review.googlesource.com/35918
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
The current ARM implementation assumes that the input message
is memory aligned and so it can cause alignment fault when it
is not enabled. Also it may generate incorrect outputs in ARMv5.
This change fixes this issue by temporarily copying the input
to a local aligned space. Although there may be a better way
to handle unaligned access, this would be a safe way in all
ARM versions.
This change also added a test and benchmarks with unaligned
data. The benchmark result on RasberryPI 2 is
Benchmark64 2000000 812 ns/op 78.81 MB/s
Benchmark1K 200000 7809 ns/op 131.12 MB/s
Benchmark64Unaligned 2000000 967 ns/op 66.13 MB/s
Benchmark1KUnaligned 200000 10316 ns/op 99.26 MB/s
Change-Id: I189cc1b7bb6c67a04c9877271fb27326f2896e82
Reviewed-on: https://go-review.googlesource.com/12797
Reviewed-by: Adam Langley <agl@golang.org>
Adam Langley
Michael Munday
Jungho Ahn