| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This should help distros and Crypto++ test scripts
|
| |
|
|
|
|
| |
Copy/paste error from the regular GNUmakefile
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The Apple assembler cannot translate the source files for iOS.
|
|
|
|
| |
It looks like AES needed -mthumb for Clang. SHA must not use -mthumb under Clang due to a crash.
|
|
|
|
|
|
|
| |
Cryptogams is Andy Polyakov's project used to create high speed crypto algorithms and share them with other developers. Cryptogams has a dual license. First is the OpenSSL license because Andy contributes to OpenSSL. Second is a BSD license for those who want a more permissive license.
Andy's implementation runs about 45% faster than C/C++ code. Testing on a 1.8 GHz Cortex-A17 shows Cryptograms at 45 cpb, and C++ at 79 cpb.
The integration instructions are documented at [Cryptogams SHA](https://wiki.openssl.org/index.php/Cryptogams_SHA) on the OpenSSL wiki.
|
|
|
|
|
|
|
| |
Cryptogams is Andy Polyakov's project used to create high speed crypto algorithms and share them with other developers. Cryptogams has a dual license. First is the OpenSSL license because Andy contributes to OpenSSL. Second is a BSD license for those who want a more permissive license.
Andy's implementation runs about 45% faster than C/C++ code. Testing on a 1 GHz Cortex-A7 shows Cryptograms at 17 cpb, and C++ at 30 cpb.
The integration instructions are documented at [Cryptogams SHA](https://wiki.openssl.org/index.php/Cryptogams_SHA) on the OpenSSL wiki.
|
|
|
|
|
|
|
|
|
| |
Add ARM SHA1 asm implementation from Cryptogams.
Cryptogams is Andy Polyakov's project used to create high speed crypto algorithms and share them with other developers. Cryptogams has a dual license. First is the OpenSSL license because Andy contributes to OpenSSL. Second is a BSD license for those who want a more permissive license.
Andy's implementation runs about 30% faster than C/C++ code. Testing on a 1 GHz Cortex-A7 shows Cryptograms at 16 cpb, and C++ at 23 cpb.
The integration instructions are documented at [Cryptogams SHA](https://wiki.openssl.org/index.php/Cryptogams_SHA) on the OpenSSL wiki.
|
| |
|
| |
|
| |
|
|
|
|
| |
This mirrors PR #815, where we used CXXFLAGS instead of TCXXFLAGS for feature tests
|
|
|
|
|
|
|
|
|
|
| |
The makefile tries to pre-qualify NEON (for lack of a better term), and sets IS_NEON accordingly. If IS_NEON=1, then we go on to perform test compiles to see if -mfloat-abi=X -mfpu=neon (and friends) actually work. Effectively we are performing a test to see if we should perform another test.
The IS_NEON flag predates our compile time feature tests. It was kind of helpful when we were trying to sort out if a platform and compiler options supported NEON without a compile test. That was an absolute mess and we quickly learned we needed a real compile time feature test (which we now have).
Additionally, Debian and Fedora ARMEL builds are failing because we are misdetecting NEON availability. It looks like we fail to set IS_NEON properly, so we never get into the code paths that set either (1) -mfloat-abi=X -mfpu=neon or (2) -DCRYPTOPP_DISABLE_NEON or -DCRYPTOPP_DISABLE_ASM. Later, the makefile builds a *_simd.cpp and the result is an error that NEON needs to be activated (or disabled).
This commit removes IS_NEON so we immediately move to compile time feature tests.
|
|
|
|
| |
Fedora 7 toolchain supplies upto SSE4.2
|
| |
|
|
|
|
| |
Solaris lacks a GNU compatible install program in /usr/bin and /usr/xpg4/bin. Just use cp and chmod. Cp and chmod work everywhere
|
| |
|
|
|
|
| |
Moon's code is very fast. In fact it is so fast it broke our benchmarks. Moon's code registers 0.00 milliseconds and 0.00 megacycles/operation.
|
|
|
|
| |
They use a hardened build and include flags like -Werror=XXX and -Wp,FORTIFY_SOURCE
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also see https://groups.google.com/forum/#!topic/cryptopp-users/HBz-6gZZFOA on the mailing list
|
|
|
|
|
| |
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 stops the inclusion of SSE headers without arch options that break the recipe
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also see https://groups.google.com/forum/#\!topic/cryptopp-users/j_aQj6r-PoI
|
| |
|
|
|
|
| |
Also see https://groups.google.com/forum/#\!topic/cryptopp-users/j_aQj6r-PoI
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Rename regtest3.cpp to regtest4.cpp. Split regtest2.cpp into regtest2.cpp and regtest3.cpp
|
|
|
|
| |
Renamed bench2.cpp to bench3.cpp. Split bench1.cpp into bench1.cpp and bench2.cpp
|