The code at check-in a5c67cfdd6 did not include it. Unlike Threefish, it looks like Kalyna could benefit from the cache hardening given how similar Kalyna is to AES. The hardening costs less than 0.1 cpb, which equates to about 199 MB/s vs 201 MB/s on a 6th gen Skylake
CRYPTOPP_COVERAGE was added at 9614307ab7 to increase code coverage support. This commit enables additional validation routines when CRYPTOPP_COVERAGE is in effect.
VariableBlockSize and VariableBlockCipherImpl were added at Commit bd8edfa87b. Reflecting on FixedKeyLength and VariableKeyLength, the const KEYLENGTH is only provided by FixedKeyLength. VariableKeyLength provides DEFAULT_KEYLENGTH. This check-in makes VariableBlockSize follow VariableKeyLength.
This check-in also splits block size and iv length. Its conceivable we will encounter a cipher with a block size of 128-bits with an iv of 256-bits. The bd8edfa87b check-in could not handle the difference, so we fix it now.
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.
Jeffrey Walton
Anton Gorev