AES-XEX is a building block for other cryptographic standards and not yet a
standard in and of itself. We'll just provide the standardized AES-XTS
algorithm, and not AES-XEX. The AES-XTS algorithm and interface provided
can be used to perform the AES-XEX algorithm when the length of the input
is a multiple of the AES block size.
If we're unlucky with memory placement, gf128mul_table_bbe may spread over
two cache lines and this would leak b >> 63 to a cache timing attack.
Instead, take an approach that is less likely to make different memory
loads depending on the value of b >> 63 and is also unlikely to be compiled
to a condition.
XTS mode is fully known as "xor-encrypt-xor with ciphertext-stealing".
This is the generalization of the XEX mode.
This implementation is limited to an 8-bits (1 byte) boundary, which
doesn't seem to be what was thought considering some test vectors [1].
This commit comes with tests, extracted from [1], and benchmarks.
Although, benchmarks aren't really nice here, as they work with a buffer
of a multiple of 16 bytes, which isn't a challenge for XTS compared to
XEX.
[1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip
As seen from the first benchmark run, AES-XEX was running pourly (even
slower than AES-CBC). This commit doubles the performances of the
current implementation.
The test cases come from the XTS test vectors given by the CAVP initiative
from NIST (see [1]).
As mentioned in a previous commit, XEX is a simpler case of XTS.
Therefore, to construct the test_suite_aes.xex.data file, extraction of
the XEX-possible cases has been done on the given test vectors.
All of the extracted test vectors pass the tests on a Linux x86_64 machine.
[1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip
XEX mode, known as "xor-encrypt-xor", is the simple case of the XTS
mode, known as "XEX with ciphertext stealing". When the buffers to be
encrypted/decrypted have a length divisible by the length of a standard
AES block (16), XTS is exactly like XEX.
When MBEDTLS_PLATFORM_MEMORY is defined but MBEDTLS_PLATFORM_FREE_MACRO or
MBEDTLS_PLATFORM_CALLOC_MACRO are not defined then the actual functions
used to allocate and free memory are stored in function pointers.
These pointers are exposed to the caller, and it means that the caller
and the library have to share a data section.
In TF-A, we execute in a very constrained environment, where some images
are executed from ROM and other images are executed from SRAM. The
images that are executed from ROM cannot be modified. The SRAM size
is very small and we are moving libraries to the ROM that can be shared
between the different SRAM images. These SRAM images could import all the
symbols used in mbedtls, but it would create an undesirable hard binary
dependency between the different images. For this reason, all the library
functions in ROM are accesed using a jump table whose base address is
known, allowing the images to execute with different versions of the ROM.
This commit changes the function pointers to actual functions,
so that the SRAM images only have to use the new exported symbols
(mbedtls_calloc and mbedtls_free) using the jump table. In
our scenario, mbedtls_platform_set_calloc_free is called from
mbedtls_memory_buffer_alloc_init which initializes the function pointers
to the internal buffer_alloc_calloc and buffer_alloc_free functions.
No functional changes to mbedtls_memory_buffer_alloc_init.
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Adds error handling into mbedtls_aes_crypt_ofb for AES errors, a self-test
for the OFB mode using NIST SP 800-38A test vectors and adds a check to
potential return errors in setting the AES encryption key in the OFB test
suite.
