| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
We think this is another instance problem that surfaced under GH #683 when inString==outString. It violates aliasing rules and the compiler begins removing code.
The ultimate workaround was to add a member variable m_tempOutString as scratch space when inString==outString. We did not loose much in the way of perforamce for some reason. It looks like AES/CTR lost about 0.03-0.05 cpb.
When combined with the updated xorbuf from GH #1020, the net result was a speedup of 0.1-0.6 cpb. In fact, some ciphers like RC6, gained almost 5 cpb.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This helps contain UB on pointer subtraction by ensuring a ptrdiff_t is used. The code is a little uglier but it is also more portable.
|
| |
|
|
|
|
| |
Increase use of ptrdiff_t when performing pointer math
Reduce AlgorithmProvider overrides
Fix CPU_ProbeARMv7 on Aarch64
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Some authenticated encryption modes have needs that are not expressed well with MandatoryBlockSize() and MinLastBlockSize(). When IsLastBlockSpecial() returns true three things happen. First, standard block cipher padding is not applied. Second, the ProcessLastBlock() is used that provides inString and outString lengths. Third, outString is larger than inString by 2*MandatoryBlockSize(). That is, there's a reserve available when processing the last block.
The return value of ProcessLastBlock() indicates how many bytes were written to outString. A filter driving data will send outString and returned length to an AttachedTransformation() for additional processing.
|
| |
|
|
|
| |
The strategy of "cleanup under-aligned buffers" is not scaling well. Corner cases are still turing up. The library has some corner-case breaks, like old 32-bit Intels. And it still has not solved the AltiVec and Power8 alignment problems.
For now we are backing out the changes and investigating other strategies
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit supports the upcoming AltiVec and Power8 processor support. The commit favors AlignedSecByteBlock over SecByteBlock in places where messages are handled on the AltiVec and Power8 processor data paths. The data paths include all block cipher modes of operation, and some filters like
Intel and ARM processors are tolerant of under-aligned buffers when using crypto intstructions. AltiVec and Power8 are less tolerant, and they simply ignore the three low-order bits to ensure an address is aligned. The AltiVec and Power8 have caused a fair number of wild writes on the stack and in the heap.
Testing on a 64-bit Intel Skylake show a marked improvement in performance. We suspect GCC is generating better code since it knows the alignment of the pointers, and does not have to emit fixup code for under-aligned and mis-aligned data. Here are some data points:
SecByteBlock
- Poly1305: 3.4 cpb
- Blake2s: 6.7 cpb
- Blake2b: 4.5 cpb
- SipHash-2-4: 3.1 cpb
- SipHash-4-8: 3.5 cpb
- ChaCha20: 7.4 cpb
- ChaCha12: 4.6 cpb
- ChaCha8: 3.5 cpb
AlignedSecByteBlock
- Poly1305: 2.9 cpb
- Blake2s: 5.5. cpb
- Blake2b: 3.9 cpb
- SipHash-2-4: 1.9 cpb
- SipHash-4-8: 3.3 cpb
- ChaCha20: 6.0 cpb
- ChaCha12: 4.0 cpb
- ChaCha8: 2.9 cpb
Testing on an mid-2000's 32-bit VIA C7-D with SSE2+SSSE3 showed no improvement, and no performance was lost.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);
|
| | |
|
| |
|
|
| |
We have made a fair number of changes, and we don't want WD to receive credit for issues he was not part of
|
| | |
|
| |
|
|
| |
Also see https://github.com/weidai11/cryptopp/commit/399a1546de71f41598c15edada28e7f0d616f541#commitcomment-19448453
|
| |
|
|
| |
behavior pivots on CRYPTOPP_DEBUG, and not NDEBUG (Issue 277, CVE-2016-7420)
|
| |
|
|
| |
trap.h and CRYPTOPP_ASSERT has existed for over a year in Master. We deferred on the cut-over waiting for a minor version bump (5.7). We have to use it now due to CVE-2016-7420
|
| |
|
|
| |
(Issue 255)
|
| |
|
|
| |
(Coverity rollup)
|
| | |
|
| |
|
|
| |
Fixes issue #45
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- speed up GCM key setup
- wipe stack in AES assembly code
- speed up CFB mode
|
| |
|
|
|
|
| |
- added AuthenticatedSymmetricCipher interface class and Filter wrappers
- added CCM, GCM (with SSE2 assembly), CMAC, and SEED
- improved AES speed on x86 and x64
- removed WORD64_AVAILABLE; compiler 64-bit int support is now required
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
