This cleans up the compile on old PwerMac G5's. Our Altivec and Crypto code relies on Power7 and Power8 extensions. There's no need to shoehorn Altivec and Power4 into old platforms, so we disable Altivec and Crypto unless Power7 is available. The GNUmakefile sets CRYPTOPP_DISABLE_ALTIVEC if Power7 is not available.
Enable aligned allocations under IBM XL C/C++. Based on the AIX malloc man pages, "... the block is aligned so that it can be used for any type of data". Previously CRYPTOPP_NO_ALIGNED_ALLOC was in effect.
Use malloc instead of calloc on OS X. Based on the OS X malloc man pages, "... the allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types". Additionally, calloc zero'd the memory it allocated which slowed things down on Apple systems.
This is the first of possibly two or three for Borland compilers. We have to be careful because its very easy to break something due to math overloads with other compilers like SunCC or XL/C
This avoids the probe for SSE2 in most circumstances. The SSE2 test is mostly benign nowadays since SSE2 and OS support is nearly ubiquitous. But the define CRYPTOPP_NO_CPU_FEATURE_PROBES added for Apple OSes was interacting badly on x86 machines. Also see GH #511.
UncheckedSetKey has traditionally been a protected member function. The public API traditionally uses SetKey (and friends) to set the key. Internally, SetKey may call UncheckedSetKey. It looks like UncheckedSetKey was made public when authenticated encryption support was added.
Its probably not a good idea to have users calling UncheckedSetKey. Most (all?) of the time it does nothing for authenc modes. The other remaining cases it may not work as expected.
Move m_aliasBlock into Rijndael::Base. m_aliasBlock is now an extra data member for Dec because the aliased table is only used for Enc when unaligned data access is in effect. However, the SecBlock is not allocated in the Dec class so there is no runtime penalty.
Moving m_aliasBlock into Base also allowed us to remove the Enc::Enc() constructor, which always appeared as a wart in my eyes. Now m_aliasBlock is sized in UncheckedSetKey, so there's no need for the ctor initialization.
Also see https://stackoverflow.com/q/46561818/608639 on Stack Overflow. The SO question had an unusual/unexpected interaction with CMake, so the removal of the Enc::Enc() ctor should help the problem.
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.
This provides the functions needed for an implementation. It does not provide the implementation itself
Signed-off-by: Jeffrey Walton <noloader@gmail.com>
