The commit also adds an assert on memcpy_s pointers. GCC 8 claims the pointers are the same. We think it is a spurious finding. The assert never fired during test.
The ALTIVEC function required an inline declaration. Lack of inline caused the self test failure. Two NEON functions needed the same. We also cleaned up constants in unnamed namespaces
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>
The code below was flagged by undefined behavior santizier under GCC 8. The offender was the doubling at "r4 = vec_add(r4, r4)". R4 is rcon and an unsigned type. It depends on integer wrap but GCC is generating code that is being flagged for signed overflow. GCC 7 and below is OK.
for (unsigned int i=0; i<8; ++i)
{
r1 = Rijndael_Subkey_POWER8(r1, r4, r5);
r4 = vec_add(r4, r4);
skptr = IncrementPointerAndStore(r1, skptr);
}
// Final two rounds using table lookup
...
Throughout the library the message "FAILED" (not "failed") is used to signal failures. It makes it easy to grep for them. This change makes the message consistent.
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
Jeffrey Walton
Nicolas Chauvet (kwizart)
Jan Beich