Of the 200+ test vectors only 10 are semi-authentic. The ten are from the Simon and Speck paper but they had permutations applied to them so they worked with the algorithms described in the paper. The remaining 200 or so were generated with Crypto++ using straight C++ code. The library generated the test vectors because we don't have a reference implementation
$ CXXFLAGS=-std=gnu++17 gmake
clang++ -std=gnu++17 -fPIC -pthread -pipe -c cryptlib.cpp
In file included from cryptlib.cpp:19:
./misc.h:2542:43: error: no member named 'bind2nd' in namespace 'std'
return std::find_if(first, last, std::bind2nd(std::not_equal_to<T>(), value));
~~~~~^
1 error generated.
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...
It is easier to defer to the runtime for aligned allocations. We found the preprocessor macros needed to identitify the availability. Also see https://forum.kde.org/viewtopic.php?p=66274
It is easier to defer to the runtime for aligned allocations. We found the preprocessor macros needed to identitify the availability. Also see https://forum.kde.org/viewtopic.php?p=66274
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.
Analysis tools are generating findings when the pointer xorBlocks is used as the flag. The other missing piece is, xorBlocks is never NULL when either BT_XorInput or BT_XorOuput. But we don't know how to train the analyzers with the information, so we make it explicit with the boolean flags xorInput and xorOutput.
Switching to the explicit flags costs us about 0.01 cpb on a modern Intel Core processor. In the typical case 0.01 is negligible.
Jeffrey Walton
Jan Beich
zorun
XU Cheng