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...
This commit does a few things. First, it uses the compiler's triplet and the build component to determine the machine we are targeting. Second, it adds an 'X' prefix so we don't collide with someone else's variables. Third it cleans up some of the recipes. Fourth, it removes X32 detection since the system differences are handled in config.h and the source files
Linuxbrew is a fork of Homebrew on Linux.
In which, the `gcc --version` will report "homebrew".
Therefore, the current code will incorrectly set OSXPORT_COMPILER
under such environment, which results to the following compiling errors:
gcm.cpp:823: Error: too many memory references for `add'
gcm.cpp:824: Error: too many memory references for `pxor'
gcm.cpp:825: Error: ambiguous operand size for `shr'
gcm.cpp:826: Error: too many memory references for `movzx'
gcm.cpp:827: Error: too many memory references for `add'
gcm.cpp:828: Error: too many memory references for `pxor'
gcm.cpp:829: Error: too many memory references for `movzx'
gcm.cpp:830: Error: too many memory references for `add'
gcm.cpp:831: Error: too many memory references for `pxor'
gcm.cpp:832: Error: ambiguous operand size for `add'
gcm.cpp:833: Error: ambiguous operand size for `sub'
gcm.cpp:835: Error: too many memory references for `movdqa'
g++-5 -DNDEBUG -g2 -O3 -fPIC -Wa,-q -DCRYPTOPP_CLANG_INTEGRATED_ASSEMBLER=1 -pthread -pipe -c md4.cpp
make: *** [GNUmakefile:1120: gcm.o] Error 1
make: *** Waiting for unfinished jobs....
Fix this problem by checking IS_DARWIN before setting OSXPORT_COMPILER.
TweetNaCl is a compact reimplementation of the NaCl library by Daniel J. Bernstein, Bernard van Gastel, Wesley Janssen, Tanja Lange, Peter Schwabe and Sjaak Smetsers. The library is less than 20 KB in size and provides 25 of the NaCl library functions.
The compact library uses curve25519, XSalsa20, Poly1305 and SHA-512 as default primitives, and includes both x25519 key exchange and ed25519 signatures. The complete list of functions can be found in TweetNaCl: A crypto library in 100 tweets (20140917), Table 1, page 5.
Crypto++ retained the function names and signatures but switched to data types provided by <stdint.h> to promote interoperability with Crypto++ and avoid size problems on platforms like Cygwin. For example, NaCl typdef'd u64 as an unsigned long long, but Cygwin, MinGW and MSYS are LP64 systems (not LLP64 systems). In addition, Crypto++ was missing NaCl's signed 64-bit integer i64.
Crypto++ enforces the 0-key restriction due to small points. The TweetNaCl library allowed the 0-keys to small points. Also see RFC 7748, Elliptic Curves for Security, Section 6.
TweetNaCl is well written but not well optimized. It runs 2x to 3x slower than optimized routines from libsodium. However, the library is still 2x to 4x faster than the algorithms NaCl was designed to replace.
The Crypto++ wrapper for TweetNaCl requires OS features. That is, NO_OS_DEPENDENCE cannot be defined. It is due to TweetNaCl's internal function randombytes. Crypto++ used DefaultAutoSeededRNG within randombytes, so OS integration must be enabled. You can use another generator like RDRAND to avoid the restriction.
This commit also tweaks the way Integer parses byte arrays. The modified routines are slightly faster. On a Core-i5 6400 the self tests are 0.1 to 0.2 seconds faster
* GNUmakefile-cross: Fix install target
The install target was not working: missing mkdir before copying files,
wrong dynamic library copied, missing ldconf.
The fix is mostly taken from the install target from GNUmakefile.
* Makefile: call 'ln -sf' instead of 'ln -sf -sf'
AES does not have a NEON implementation. However, because it includes "adv-simd.h", it needs the compiler options so NEON types are available. Otherwise the compile fails.
We can't guard "adv-simd.h" and NEON on just AES because Simon and Speck use the templates in their NEON implementations.
ARM64 is kind of useless. We need A-32 (old ARM), Aarch32 (new 32-bit ARM) and Aarch64 (new 64-bit ARM). Aarch32 and Aarch64 is captured by IS_ARMV8, and A-32 is captured by IS_ARM
Performance increased by about 100% on a 3.1 GHz Core i5 Skylake. Throughput went from about 7.3 cpb to about 3.5 cpb. Not bad for a software-based implementation of a block cipher
We need to ensure SSE2 does not cross pollinate into other CPU functions since SSE2 is greater than the minimum arch. The minimum arch is i586/i686, and both lack SSE2 instructions
* Set default target Windows version for MinGW to XP
The original MinGW from mingw.org targets Windows 2000 by default, but lacks
the <wspiapi.h> include needed for Windows 2000 support.
* Disable CRYPTOPP_CXX11_SYNCHRONIZATION for original MinGW
std::mutex is only available in libstdc++ if _GLIBCXX_HAS_GTHREADS is defined,
which is not the case for original MinGW. Make the existing fix for AIX more
general to fix this. Unfortunately, any C++ header has to be included to
detect the standard library and the otherwise empty <ciso646> is going to be
removed from C++20, so use <cstddef> instead.
This cleans up the compile on old PwerMac G5's. Our Altivec and Crypto code relies on Power7 and Power8 extensions. There's no need to shoehorn Altivec and Power4 into old platforms, so we disable Altivec and Crypto unless Power7 is available. The GNUmakefile sets CRYPTOPP_DISABLE_ALTIVEC if Power7 is not available.
Jeffrey Walton
Tanzinul Islam
Nicolas Chauvet (kwizart)
XU Cheng
zorun
Marcel Raad