-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AES-CTS mode will fail when inlen = 0x100, in_incr = 0x80 #1203
Comments
Have you tested your hypothesis? |
@jenswi-linaro Yes, I have tested it. The origin test cases in xtest works, and this situation also work. But I'm not sure whether I have the right idea or not. |
If it works I'd say it's OK. The objective of |
@jenswi-linaro maybe it's not the best fix. It seems +1 is need when op->buffer_two_blocks is false, in order to feed as much as possible? But when op->buffer_two_blocks is true, I think the +1 is not need, in order to keep at least (block_size + 1) leave to the final. |
@lackan do you have a test vector we could add to |
@jforissier I don't have a test vector, I just do some benchmark test, to test different size in different mode, so I don't care the result, just care whether the mode run success or not. |
Makes the ROUNDUP() call in the "feeding from src" case consistent with the "feeding from buffer" case a few lines earlier. Without this fix, AES CTR encryption or decryption could fail because update would feed blocks too soon, leaving less than two blocks in the internal buffer thus causing utee_cipher_final (called from TEE_CipherDoFinal()) to fail and panic the TA. Fixes: OP-TEE#1203 Signed-off-by: Jerome Forissier <[email protected]>
Makes the ROUNDUP() call in the "feeding from src" case consistent with the "feeding from buffer" case a few lines earlier. Without this fix, AES CTR encryption or decryption could fail because update would feed blocks too soon, leaving less than two blocks in the internal buffer thus causing utee_cipher_final() (called from TEE_CipherDoFinal()) to fail and panic the TA. Fixes: OP-TEE#1203 Signed-off-by: Jerome Forissier <[email protected]>
Add test case for issue OP-TEE/optee_os#1203. Signed-off-by: Jerome Forissier <[email protected]>
Add test case for issue OP-TEE/optee_os#1203. Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Makes the ROUNDUP() call in the "feeding from src" case consistent with the "feeding from buffer" case a few lines earlier. Without this fix, AES CTR encryption or decryption could fail because update would feed blocks too soon, leaving less than two blocks in the internal buffer thus causing utee_cipher_final() (called from TEE_CipherDoFinal()) to fail and panic the TA. Fixes: OP-TEE#1203 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Makes the ROUNDUP() call in the "feeding from src" case consistent with the "feeding from buffer" case a few lines earlier. Without this fix, AES CTR encryption or decryption could fail because update would feed blocks too soon, leaving less than two blocks in the internal buffer thus causing utee_cipher_final() (called from TEE_CipherDoFinal()) to fail and panic the TA. Fixes: OP-TEE/optee_os#1203 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Hi,
As the title say, when I test the AES-CTS mode using this input, which inlen = 0x100, and in_incr = 0x80, it will fail. And I try to find out what's the reason, then I add trace to this situation, and see the fuction tee_aes_cbc_cts_update will deal with the input len as follow: (0x70)->(0x20)->(0x60)->(0x10), so the last input len it deal with is 0x10, it's not fit for the constraints(blocks >= 2) .
it may be have a bug in function tee_buffer_update, the code as below:
I think
l = ROUNDUP(slen - buffer_size + 1, op->block_size)
should change tol = ROUNDUP(slen - buffer_size, op->block_size)
, no need to increase 1, what do you think?The text was updated successfully, but these errors were encountered: