-
Notifications
You must be signed in to change notification settings - Fork 830
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
20240516-wc_AesXtsEnDecryptFinal #7549
20240516-wc_AesXtsEnDecryptFinal #7549
Conversation
…API consistency, and add error-checking (block alignment check) to wc_AesXtsEncryptUpdate() and wc_AesXtsDecryptUpdate().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SparkiDev please review
{ | ||
int ret; | ||
if (sz > 0) | ||
ret = AesXtsEncryptUpdate(xaes, out, in, sz, i); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this input "sz" not have to be multiple of block size?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's right. for the last call, the input can have any length >= AES_BLOCK_SIZE
. if the length isn't a multiple of the block size, then the ciphertext stealing stuff is used to finish out the message. and btw that's exactly why only the last call can be non-block-aligned.
return AesXtsEncryptUpdate(xaes, out, in, sz, i); | ||
} | ||
|
||
int wc_AesXtsEncryptFinal(XtsAes* xaes, byte* out, const byte* in, word32 sz, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What value does "final" add? Is it the zero'ing of "i"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a couple things:
(1) lets us add error-checking for all calls to Update()
to make sure they're correctly block-aligned (trying to get ahead of ZenDesk tickets on that).
(2) the zeroing lets us check for API abuse, in that it guarantees a wrong result if the user calls Update after a Final, and of course it also prevents anything valuable from leaking out through the IV.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Answers satisfy my concerns. @SparkiDev please finalize. Thanks
…yptFinal 20240516-wc_AesXtsEnDecryptFinal
AES-XTS: add
wc_AesXtsEncryptFinal()
andwc_AesXtsDecryptFinal()
for API consistency, and add error-checking (block alignment check) towc_AesXtsEncryptUpdate()
andwc_AesXtsDecryptUpdate()
.tested with
wolfssl-multi-test.sh ... linuxkm-aesxts-cryptonly-noasm-LKCAPI-no-twc-insmod-crypto-fuzzer linuxkm-aesxts-cryptonly-aesni-LKCAPI-no-twc-insmod-crypto-fuzzer linuxkm-aesxts-cryptonly-noasm-ECB-LKCAPI-no-twc-insmod-crypto-fuzzer linuxkm-aesxts-cryptonly-aesni-ECB-LKCAPI-no-twc-insmod-crypto-fuzzer linuxkm-fips-dev-static-hash-intelasm-LKCS-insmod-6.1.73-fortify check-source-text all-g++