Searched hist:"16 a1c178aa73bab8444dd91dc75f4d96e5620eda" (Results 1 – 2 of 2) sorted by relevance
| /optee_os/core/crypto/ |
| H A D | cbc-mac.c | 16a1c178aa73bab8444dd91dc75f4d96e5620eda Fri Jul 09 12:06:13 UTC 2021 Jerome Forissier <jerome@forissier.org> crypto: optimize speed of AES CBC MAC
The current AES CBC MAC implementation invokes the AES CBC algorithm via
crypto_cipher_update() for each 16-byte block of the input data. This
can be inefficient especially with hardware accelerated implementations
which may have a significant overhead (I am thinking of proprietary
implementations of MBed TLS for example).
This commit introduces a new config option:
CFG_CRYPTO_CBC_MAC_BUNDLE_BLOCKS (default 64) which allows to bundle
several 16-byte blocks of input data when calling the AES CBC function.
Therefore with the default value, data are processed 1 KB at a time
(assuming the caller provides enough data of course). There is a small
memory overhead (malloc) of the same size at most.
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|
| /optee_os/core/ |
| H A D | crypto.mk | 16a1c178aa73bab8444dd91dc75f4d96e5620eda Fri Jul 09 12:06:13 UTC 2021 Jerome Forissier <jerome@forissier.org> crypto: optimize speed of AES CBC MAC
The current AES CBC MAC implementation invokes the AES CBC algorithm via
crypto_cipher_update() for each 16-byte block of the input data. This
can be inefficient especially with hardware accelerated implementations
which may have a significant overhead (I am thinking of proprietary
implementations of MBed TLS for example).
This commit introduces a new config option:
CFG_CRYPTO_CBC_MAC_BUNDLE_BLOCKS (default 64) which allows to bundle
several 16-byte blocks of input data when calling the AES CBC function.
Therefore with the default value, data are processed 1 KB at a time
(assuming the caller provides enough data of course). There is a small
memory overhead (malloc) of the same size at most.
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|