Previously, all 1024-bit tests were run, and then 2048-bit tests were run. Splitting them meant there were two entries for DSA-RFC6979/SHA-1, two entries for DSA-RFC6979/SHA-256 and so on. Now there will be one entry output during testing.
sha2.txt and sha3.txt are just collections of other files, so they don't take up much space.
This commit stens from and exception when running 'cryptest.exe tv sha2' and 'cryptest.exe tv sha3'. Its not obvious the name of the file to be run sha2_224_fips_180.txt. Users should not have to hunt for the reason sha2 and sha3 do not work.
sha2.txt and sha3.txt are just collections of other files, so they don't take up much space.
This commit stens from and exception when running 'cryptest.exe tv sha2' and 'cryptest.exe tv sha3'. Its not obvious the name of the file to be run sha2_224_fips_180.txt. Users should not have to hunt for the reason sha2 and sha3 do not work.
regtest.cpp is where ciphers register by name. The library has added a number of ciphers over the last couple of years and the source file has experienced bloat. Most of the ARM and MIPS test borads were suffering Out of Memory (OOM) kills as the compiler processed the source fille and the included header files.
This won't stop the OOM kills, but it will help the situation. An early BeagleBoard with 512 MB of RAM is still going to have trouble, but it can be worked around by building with 1 make job as opposed to 2 or 4.
The ARIA S-boxes could leak timining information. This commit applies the counter measures present in Rijndael and Camellia to ARIA. We take a penalty of about 0.05 to 0.1 cpb. It equates to about 0 MiB/s on an ARM device, and about 2 MiB/s on a modern Skylake.
We recently gained some performance though use of SSE and NEON in ProcessAndXorBlock, so the net result is an improvement.
Tune CRYPTOPP_ENABLE_ARIA_SSE2_INTRINSICS and CRYPTOPP_ENABLE_ARIA_SSSE3_INTRINSICS macro for older GCC and Clang. Clang needs some more tuning on Aarch64 becuase performance is off by about 15%.
Add additional NEON code paths.
Remove keyBits from Aarch64 code paths.
The SSSE3 intrinsics were performing aligned loads using _mm_load_si128 using user supplied pointers. The pointers are only a byte pointer, so its alignment can drop to 1 or 2. Switching to _mm_loadu_si128 will sidestep potential problems. The crash surfaced under Win32 testing.
Switch to memcpy's when performing bulk assignment x[0]=y[0] ... x[3]=y[3]. I believe Yun used the pattern to promote vectorization. Some compilers appear to be braindead and issue integer move's one word at a time. Non-braindead compiler will still take the optimization when advantageous, and slower compilers will benefit from the bulk move. We also cherry picked vectorization opportunities, like in ARIA_GSRK_NEON.
Remove keyBits variable. We now use UncheckedSetKey's keylen throughout.
Also fix a typo in CRYPTOPP_BOOL_SSSE3_INTRINSICS_AVAILABLE. __SSSE3__ was listed twice.
Win32 and Win64 benefited from the Intel intrinsics. A32 and Aarch64 benefited from the ARM intrinsics. The intrinsics shaved 150 to 350 cycles from key setup.
The intrinsics slowed modern GCC down a small bit, and did not appear to affect old GCC. As such, Intel intrinsics were only enabled for Microsoft compilers.
We were not able to improve encryption and decryption. In fact, some of the attempted macro conversions and intrinsics attempts slowed things down considerably. For example, GCC 5.4 on x86_64 went from 120 MB/s to about 70 MB/s when we tried to improve code around the Key XOR Layer (ARIA_KXL).
This is the reference implementation, test data and test vectors from the ARIA.zip package on the KISA website. The website is located at http://seed.kisa.or.kr/iwt/ko/bbs/EgovReferenceList.do?bbsId=BBSMSTR_000000000002.
We have optimized routines that improve Key Setup and Bulk Encryption performance, but they are not being checked-in at the moment. The ARIA team is updating its implementation for contemporary hardware and we would like to use it as a starting point before we wander too far away from the KISA implementation.
Couple use of initialization priorities to no NO_OS_DEPENDENCE
Add comments explaining what integer does, how it does it, and why we want to inprove on the Singleton pattern as a resource manager.
Update documentation.
This effectively decouples Integer and Public Key from the rest of the library. The change means a compile time define is used rather than a runtime pointer. It avoids the race with Issue 389.
The Public Key algorithms will fail if you use them. For example, running the self tests with CRYPTOPP_NO_ASSIGN_TO_INTEGER in effect results in "CryptoPP::Exception caught: NameValuePairs: type mismatch for 'EquivalentTo', stored 'i', trying to retrieve 'N8CryptoPP7IntegerE'". The exception is expected, and the same happend when g_pAssignIntToInteger was present.
This check-in also enables the 64-bit RDRAND routines for X32. The changes were with held until they could be tested. The testing occurred with Issue 395
Wrap DetectArmFeatures and DetectX86Features in InitializeCpu class
Use init_priority for InitializeCpu
Remove HAVE_GCC_CONSTRUCTOR1 and HAVE_GCC_CONSTRUCTOR0
Use init_seg(<name>) on Windows and explicitly insert at XCU segment
Simplify logic for HAVE_GAS
Remove special recipies for MACPORTS_GCC_COMPILER
Move C++ static initializers into anonymous namespace when possible
Add default NullNameValuePairs ctor for Clang
Jeffrey Walton
anonimal