This should lead the way for more modern block ciphers like Threefish and Kalyna. It tested well with both regular cipher modes (the mode has an instance of the cipher) and external cipher modes (the cipher and mode are distinct objects, and the mode holds a reference to the cipher).
We still have to work out the details of naming a cipher. For example, Kalyna with a 128-bit key can use a 128-bit or 256-bit block size. Kalyna-128 is not enough to describe the algorithm and locate it in the object registry. Kalyna-128-128 looks kind of weird; maybe Kalyna-128(128) or Kalyna-128(256) would be better.
Here are the initial test cases to verify functionality:
byte key[64] = {}, iv[32] = {};
ECB_Mode<Kalyna>::Encryption enc1;
enc1.SetKey(key, 16);
CBC_Mode<Kalyna>::Encryption enc2;
enc2.SetKeyWithIV(key, 16, iv);
AlgorithmParameters params = MakeParameters
(Name::BlockSize(), 32)
(Name::IV(), ConstByteArrayParameter(iv, 32));
CTR_Mode<Kalyna>::Encryption enc3;
enc3.SetKey(key, 16, params);
CBC_Mode<Kalyna>::Encryption enc4;
enc4.SetKey(key, 32, params);
Kalyna::Encryption enc5;
ECB_Mode_ExternalCipher::Encryption ecb(enc5);
ecb.SetKey(key, 16, params);
Kalyna::Encryption enc6;
ECB_Mode_ExternalCipher::Encryption cbc(enc6);
cbc.SetKey(key, 32, params);
This should have happened when we removed most of MAINTAIN_BACKWARDS_COMPATIBILITY artifacts. Its not practical move SHA1 into Weak:: namespace or "typedef SHA256 SHA" because SHA1 is too intertwined at the moment.
In the interim, maybe we can place SHA1 in both CryptoPP:: and Weak:: namespaces. This will allow us to transition into Weak::SHA1 over time, and signal to users SHA1 should be avoided.
They are giving ARIA and BLAKE2 trouble. It looks like SSE4 support appeared in the GCC compiler around 4.1 or 4.2. It looks like SHA support appeared in the GNU assembler around 2.18
Initially we performed a 32-bit word-size ByteReverse() on the entire 64-byte buffer being hashed. Then we performed another fix-up when loading each 16-byte portion of the buffer into the SSE2 registers for SHA processing. The [undesired] consequence was byte swapping and reversals happened twice. Worse, the call to ByteReverse() produced 16 bswaps instead of 1 call pshufb, so it was orders of magnitude slower than it needed to be.
This check-in takes the sane approach to byte reversals and swapping. It performs it once when the message is loaded for SSE processing. The result is SHA1 calculations drop from about 3.0 cpb to about 2.5 cpb.
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.
Jeffrey Walton
Anton Gorev