This will allow users to specify agreesive warning flags without accidentally failing a feature test. The feature tests are minimal but the system headers could be noisy under elevated warnings
The CORE function provides the implementation for ChaCha_OperateKeystream_ALTIVEC, ChaCha_OperateKeystream_POWER7, BLAKE2_Compress32_ALTIVEC and BLAKE2_Compress32_POWER7. Depending on the options used to compile the source files, either POWER7 or ALTIVEC will be used.
This is needed to support the "new toolchain, ancient hardware" use case.
GCM can do some bulk XOR's using the SIMD unit. However, we still need loads and stores to be fast. Fast loads and stores of unaligned data requires the VSX unit
adhoc.cpp was a bit uncomfortable because we had to copy it out from adhoc.cpp.proto. For some reason CMake could not perform the copy, so we started using pch.cpp in CMake. This commit keeps them consistent.
We may have problems with one test, and that is the Newlib tests. I seem to recall they a C++ header included to properly identify its use. We cross that bridge during MinGW testing.
This picks up about 0.2 cpb in ChaCha::OperateKeystream. It may not sound like much but it puts SSE2 intrinsics version on par with the ASM version of Salsa20. Salsa20 leads ChaCha by 0.1 to 0.15 cpb, which equates to about 50 MB/s.
I was not able to duplicate it under GCC. That includes the GCC's supplied with Debian 8 and Ubuntu 14. It looks like the problem was with Asan insread of the library
It looks like GCC is rejecting the -pthread option but it is advertising Pthread support by defining 39 related macros. I'm not sure what to make of it, but we can't use -pthread because it breaks the compile.
On my MinGW-w64 setup, the build failed:
>mingw32-make: *** No rule to make target 'winpipes.o', needed by 'libcryptopp.a'.
>mingw32-make: Target 'default' not remade because of errors.
Looks like `winpipes.cpp` was removed in f2171cbe2 but not de-listed from the `GNUmakefile`. Remove it.
SIMON-64 and SIMON-128 have different ISA requirements. The same applies to SPECK-64 and SPECK-128. GCC generated code that resulted in a SIGILL due to the ISA differences on a down level machine. The instructions was a mtfprwz from POWER8. It was prsent in a function prologue on a POWER7 machine.
I believe Andrew Marlow first reported it. At the time we could not get our hands on hardware to fully test things. Instead we were using -xmemalign=4i option as a band-aide to avoid running afoul of the Sparc instruction that moves 64-bits of data in one shot.
This PR adds ARMv8.4 cpu feature detection support. Previously we only needed ARMv8.1 and things were much easier. For example, ARMv8.1 `__ARM_FEATURE_CRYPTO` meant PMULL, AES, SHA-1 and SHA-256 were available. ARMv8.4 `__ARM_FEATURE_CRYPTO` means PMULL, AES, SHA-1, SHA-256, SHA-512, SHA-3, SM3 and SM4 are available.
We still use the same pattern as before. We make something available based on compiler version and/or preprocessor macros. But this time around we had to tighten things up a bit to ensure ARMv8.4 did not cross-pollinate down into ARMv8.1.
ARMv8.4 is largely untested at the moment. There is no hardware in the field and CI lacks QEMU with the relevant patches/support. We will probably have to revisit some of this stuff in the future.
Since this update applies to ARM gadgets we took the time to expand Android and iOS testing on Travis. Travis now tests more platforms, and includes Autotools and CMake builds, too.
Some distros don't want to install cryptest.exe. For folks who don't want to install the test program, they can issue 'make install-lib'.
install-lib is a non-standard target, but the GNU Coding Standard does not have a standard target for the task.
This is a convention that binary compatibity uses one number.
Using that, it's possible to have bugfixes releases (patchlevel
incremented) and enhancement release (minor incremented with no
public interface removed).
Here is more information about convention
https://autotools.io/libtool/version.html
(libtool isn't relevant to this project, but the explanation hold)
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
We recently learned our Simon and Speck implementation was wrong. The removal will stop harm until we can loop back and fix the issue.
The issue is, the paper, the test vectors and the ref-impl do not align. Each produces slightly different result. We followed the test vectors but they turned out to be wrong for the ciphers.
We have one kernel test vector but we don't have a working implementation to observe it to fix our implementation. Ugh...
Jeffrey Walton
Tanzinul Islam
Nicolas Chauvet (kwizart)