In ssl_server2, the private key objects are normally local variables
of the main function. However this does not hold for private keys in
the SNI configuration. When async callbacks are used, the test code
transfers the ownership of the private keys to the async callbacks.
Therefore the test code must free the SNI private keys through the
async callbacks (but it must not free the straight private keys this
way since they are not even heap-allocated).
When testing async callbacks with SNI, make all the keys async, not
just the first one. Otherwise the test is fragile with respect to
whether a key is used directly or through the async callbacks.
In the current test code, the object that is used as a public key in
the certificate also contains a private key. However this is because
of the way the stest code is built and does not demonstrate the API in
a useful way. Use mbedtls_pk_check_pair, which is not what real-world
code would do (since the private key would typically be in an external
cryptoprocessor) but is a more representative placeholder.
Rename to mbedtls_ssl_get_async_operation_data and
mbedtls_ssl_set_async_operation_data so that they're about
"async operation data" and not about some not-obvious "data".
The certificate passed to async callbacks may not be the one set by
mbedtls_ssl_conf_own_cert. For example, when using an SNI callback,
it's whatever the callback is using. Document this, and add a test
case (and code sample) with SNI.
In ssl_server2, the private key objects are normally local variables
of the main function. However this does not hold for private keys in
the SNI configuration. When async callbacks are used, the test code
transfers the ownership of the private keys to the async callbacks.
Therefore the test code must free the SNI private keys through the
async callbacks (but it must not free the straight private keys this
way since they are not even heap-allocated).
When testing async callbacks with SNI, make all the keys async, not
just the first one. Otherwise the test is fragile with respect to
whether a key is used directly or through the async callbacks.
Add a new context structure for XTS. Adjust the API for XTS to use the new
context structure, including tests suites and the benchmark program. Update
Doxgen documentation accordingly.
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.
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
