libsodium typically doesn't expose specific implementations.
It shouldn't be the case for that construction either, especially since
an ARM8 implementation might be added later.
We want a single interface for both.
* aes256gcm: (25 commits)
aes256gcm: we can expect the accumulator and the padding buffer to be aligned
aesgcm: don't expect input & output buffers to be aligned
aes256gcm doesn't use SSE4.1 instructions any more
Don't read past the AD buffer, even through an SIMD register
Convert more functions to macros
Add do { ... } while(0) when relevant
Turn reduce4 into a macro That's too much registers for a function call in 32-bit mode. And in MSVC, this is even the case if the function is marked inline.
Enable aes256gcm on Visual Studio
Don't declare new variables after a line of code
Declare __m128 arrays used as parameters as pointers Required for MSVC
Proper casts for aeskeygenassist()
Let's hope that requiring ssse3 is not required any more
Try to enable specific cflags before testing each intructions set
ssse3 target is required in addition to sse4.1
Use SIMD-specific compiler flags only for files needing them
Define __SSSE3__ if required
Do not try to compile aesni code if this is not going to compile
Check for AESNI & PCLMUL presence/usability
Replace the aes256gcm implementation with Romain Dolbeau's implementation which is slightly faster than mine. Reimplement features from the previous implementation: add batch mode and use two passes in the decryption function in order to check the tag before decrypting.
Explicit cast
...
which is slightly faster than mine.
Reimplement features from the previous implementation: add batch mode and
use two passes in the decryption function in order to check the tag before
decrypting.
sodium_memcmp() can be used to compare user-provided secrets against
constant, hardcoded secrets. We don't want the compiler to generate code
that would be optimized for these hardcoded values.
