Skip to content
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

Closed
lackan opened this issue Nov 30, 2016 · 6 comments · Fixed by #1301
Closed

AES-CTS mode will fail when inlen = 0x100, in_incr = 0x80 #1203

lackan opened this issue Nov 30, 2016 · 6 comments · Fixed by #1301

Comments

@lackan
Copy link

lackan commented Nov 30, 2016

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:

if (slen >= (buffer_size + buffer_left)) {
	l = ROUNDUP(slen - buffer_size + 1, op->block_size);
                                                                                             
	tmp_dlen = dlen;
	res = update_func(op->state, src, l, dst, &tmp_dlen);
	if (res != TEE_SUCCESS)
		TEE_Panic(res);
	src += l;
	slen -= l;
	dst += tmp_dlen;
	dlen -= tmp_dlen;
	acc_dlen += tmp_dlen;
}

I think l = ROUNDUP(slen - buffer_size + 1, op->block_size) should change to l = ROUNDUP(slen - buffer_size, op->block_size), no need to increase 1, what do you think?

@jenswi-linaro
Copy link
Contributor

Have you tested your hypothesis?

@lackan
Copy link
Author

lackan commented Nov 30, 2016

@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.

@jenswi-linaro
Copy link
Contributor

If it works I'd say it's OK. The objective of tee_buffer_update() is to feed blocks to the algorithm, if something is messed up (data out of order or lost) it should be caught by the test cases.
If you have an explanation to why this + 1 isn't needed it's even better.

@lackan
Copy link
Author

lackan commented Nov 30, 2016

@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.

@jforissier
Copy link
Contributor

@lackan do you have a test vector we could add to xtest?

@lackan
Copy link
Author

lackan commented Jan 14, 2017

@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.

jforissier added a commit to jforissier/optee_os that referenced this issue Jan 20, 2017
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]>
jforissier added a commit to jforissier/optee_os that referenced this issue Jan 20, 2017
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]>
jforissier added a commit to jforissier/optee_test that referenced this issue Jan 20, 2017
Add test case for issue OP-TEE/optee_os#1203.

Signed-off-by: Jerome Forissier <[email protected]>
jforissier added a commit to jforissier/optee_test that referenced this issue Jan 20, 2017
Add test case for issue OP-TEE/optee_os#1203.

Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jens Wiklander <[email protected]>
jforissier added a commit to jforissier/optee_os that referenced this issue Jan 20, 2017
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]>
takuya-sakata pushed a commit to renesas-rcar/optee_os that referenced this issue Dec 22, 2017
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants