OP-TEE internal AES GCM: Counter Wrap test vector failed #6659
Comments
|
xtest PR available here : OP-TEE/optee_test#726 |
|
Thanks for reporting and the xtest PR, I'm looking at the problem. |
|
I've found the issue and am working on a fix now. |
jenswi-linaro
added a commit
to jenswi-linaro/optee_os
that referenced
this issue
Jan 31, 2024
We have several AES-GCM implementations in crypto libraries and internal. The internal implementation comes in two flavours, with Arm crypto extensions (CFG_CRYPTO_WITH_CE=y) and a pure software implementation. Each block to be encrypted is xored with an encrypted counter block of equal size (16 bytes). For each block the counter is increased. Prior to this patch the entire counter block was increased as a 128-bit integer, but that's not how AES-GCM is defined. In AES-GCM only the last 32 bits of the counter block are increased, leaving the rest untouched. The difference is only noticeable when the 32 bits has reached 0xffffffff and wraps to 0x00000000 on next increment. With a 128-bit integer this would propagate into other parts of the block. Fix this by only incrementing the last 32-bit word in the counter block, both in the pure software implementation and when using Arm crypto extensions. Link: OP-TEE#6659 Fixes: 1fca7e2 ("core: crypto: add new AES-GCM implementation") Signed-off-by: Jens Wiklander <[email protected]>
|
Fix available here #6661 |
jenswi-linaro
added a commit
to jenswi-linaro/optee_os
that referenced
this issue
Jan 31, 2024
We have several AES-GCM implementations in crypto libraries and internal. The internal implementation comes in two flavours, with Arm crypto extensions (CFG_CRYPTO_WITH_CE=y) and a pure software implementation. Each block to be encrypted is xored with an encrypted counter block of equal size (16 bytes). For each block the counter is increased. Prior to this patch the entire counter block was increased as a 128-bit integer, but that's not how AES-GCM is defined. In AES-GCM only the last 32 bits of the counter block are increased, leaving the rest untouched. The difference is only noticeable when the 32 bits has reached 0xffffffff and wraps to 0x00000000 on next increment. With a 128-bit integer this would propagate into other parts of the block. Fix this by only incrementing the last 32-bit word in the counter block, both in the pure software implementation and when using Arm crypto extensions. Link: OP-TEE#6659 Fixes: 1fca7e2 ("core: crypto: add new AES-GCM implementation") Signed-off-by: Jens Wiklander <[email protected]>
|
thanks, all counter wrap test cases are successful now. |
jenswi-linaro
added a commit
to jenswi-linaro/optee_os
that referenced
this issue
Feb 1, 2024
We have several AES-GCM implementations in crypto libraries and internal. The internal implementation comes in two flavours, with Arm crypto extensions (CFG_CRYPTO_WITH_CE=y) and a pure software implementation. Each block to be encrypted is xored with an encrypted counter block of equal size (16 bytes). For each block the counter is increased. Prior to this patch the entire counter block was increased as a 128-bit integer, but that's not how AES-GCM is defined. In AES-GCM only the least significant 32 bits of the counter block are increased, leaving the rest untouched. The difference is only noticeable when the 32 bits has reached 0xffffffff and wraps to 0x00000000 on next increment. With a 128-bit integer this would propagate into other parts of the block. Fix this by only incrementing the last 32-bit word in the counter block, both in the pure software implementation and when using Arm crypto extensions. Link: OP-TEE#6659 Fixes: 1fca7e2 ("core: crypto: add new AES-GCM implementation") Signed-off-by: Jens Wiklander <[email protected]> Acked-by: Jerome Forissier <[email protected]> Acked-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this issue
Feb 1, 2024
We have several AES-GCM implementations in crypto libraries and internal. The internal implementation comes in two flavours, with Arm crypto extensions (CFG_CRYPTO_WITH_CE=y) and a pure software implementation. Each block to be encrypted is xored with an encrypted counter block of equal size (16 bytes). For each block the counter is increased. Prior to this patch the entire counter block was increased as a 128-bit integer, but that's not how AES-GCM is defined. In AES-GCM only the least significant 32 bits of the counter block are increased, leaving the rest untouched. The difference is only noticeable when the 32 bits has reached 0xffffffff and wraps to 0x00000000 on next increment. With a 128-bit integer this would propagate into other parts of the block. Fix this by only incrementing the last 32-bit word in the counter block, both in the pure software implementation and when using Arm crypto extensions. Link: #6659 Fixes: 1fca7e2 ("core: crypto: add new AES-GCM implementation") Signed-off-by: Jens Wiklander <[email protected]> Acked-by: Jerome Forissier <[email protected]> Acked-by: Etienne Carriere <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
By default optee uses the OP-TEE internal AES-GCM implementation in core/crypto.mk
(CFG_CRYPTO_AES_GCM_FROM_CRYPTOLIB ?= n)
This implementation failed with the following test vector from google/wycheproof
AES GCM test id 79
which could be added to xtest ae_cases with:
Test vector pass successfully when using libtomcrypt aes gcm implementation.
The text was updated successfully, but these errors were encountered: