Travis CI is failing on arm64 testing. Commit 0281083 is the last known good, so we are reverting to it.
The failures are unusual given things did not materially change on our side of the equation. We think something changed with Travis.
Also see https://travis-ci.community/t/segfaults-in-arm64-environment/5617.
This started as an update to travis.yml to support ARM64 testing. Autotools had a failure under Clang, and it required a modification to config_asm.h. We eventually guarded the availability defines in CRYPTOPP_DISABLE_ASM.
ANDROID_HOME is /c/Users/Jeff/.android on desktops. It is a place where user's private data goes, like Android debug signing keys. It is not the SDK directory like answered on Stack Overflow.
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.
Travis is having infrastructure problems since it migrated in November 2017. Our OS X and iOS tests hang for days. When the current job hangs, new jobs that enter the queue later hang too because the original job is still waiting.
The subsequent hangs effect Android and Linux, too. Our Travis scripts test Android, Linux, OS X and iOS. A hang effects everything.
We are going to disable Travis OS X and iOS tests until things improve.
Fix Environment setup for android to match the new unified headers.
Adjust the Makefile accordingly.
Updated the test scripts and travis to test these changes.
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.
Its a new Google Group created at https://groups.google.com/forum/#!forum/cryptopp-build. The list should allow us to run services on unprivileged forks and other unrelated accounts while making it easy to find results.
