Add m_isSpecial, m_mandatoryBlockSize and m_optimalBufferSize members. The additional members stabilize running times and avoid some unnecessary calculations. Previously we were calculating some values in each call to Put and LastPut.
CC optimizes things best when isSpecial uses the two predicates. If the 'm_cipher.MandatoryBlockSize() > 0' is removed, then some block ciphers and modes lose up to 0.2 cpb. Apparently GCC can optimize away the second predicate easier than the first predicate.
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.
StreamTransformationFilter had a small hack to accomodate AuthenticatedEncryptionFilter and AuthenticatedDecryptionFilter. The hack was enough to support CCM, EAX and GCM modes, which looks a lot like a regular stream cipher from the filter framework point of view.
OCB is slightly different. To the filter framework it looks like a block cipher with an unusual last block size and padding scheme. OCB uses MandatoryBlockSize() == BlockSize() and MinLastBlockSize() == 1 with custom padding of the last block (see the handling of P_* and A_* in the RFC). The unusual config causes the original StreamTransformationFilter assert to fire even though OCB is in a normal configuration.
For the time being, we are trying to retain the assert becuase it is a useful diagnostic. Its possible another authenticated encryption mode, like AEZ or NORX, will cause the assert to incorrectly fire (yet again). We will cross that bridge when we come to it.
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 reverts commit eb3b27a6a5. The change broke GCC 4.8 and unknown version of Clang on OS X. UB reported the OS X break, and JW found duplicated the break on a ARM CubieTruck with GCC 4.8.
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
- 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
Jeffrey Walton
danielweck
klemens
weidai