psa_cipher_update with AES-CTR fails when used in-place for a non-block-aligned size #63
Labels
No labels
api-spec
bug
CLA requested
CLA valid
compliance
DO NOT MERGE
duplicate
enhancement
feature branch
good first issue
HEADER FORMATTING ISSUE
help wanted
Information
invalid
Jira status: AWAITING REVIEW
Jira status: CLOSED
Jira status: DONE
Jira status: IN PROGRESS
Jira status: IN REVIEW
Jira status: OPEN
Jira status: REOPENED
Jira status: RESOLVED
mirrored
mirror internally
needs: backports
needs: ci
needs: design review
needs: preceding PR
needs: review
needs: work
notabug
open for community contribution
Product Backlog
question
ready for merge
security
stale
type: bug
type: enhancement
type: question
web pages
wontfix
writing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-ARMmbed/mbed-crypto#63
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Expected behavior: a call to
psa_cipher_updateon AES-CTR used with the nominal sequence of operations succeeds to encrypt 36 bytes.Actual behavior:
psa_cipher_updatereturnsPSA_ERROR_INVALID_ARGUMENT.Reported internally by @davidsaada, encountered with mbedcrypto-1.0.0d2 on Mbed OS. I reproduced it with the latest development (
72f40c6686) on Linux.Issue request type
Feeding 36 bytes of input to
cipher_encryptintest_suite_psa_cryptopasses.In the failing program, changing
datato be a larger buffer doesn't help. But changing the output to be a separate buffer does. Keeping in-place operation but changing the data size to 32 also works.So the problem is that
psa_cipher_updatedoesn't always work in-place. This is something that the PSA specification guarantees, but Mbed Crypto is known not to support, because Mbed TLS doesn't. We do however expect that in-place operation should work in cases where it does with Mbed TLS, which is the case here.Internal Jira reference: https://jira.arm.com/browse/IOTCRYPT-696
@gilles-peskine-arm Thank you for opening this issue. Trying to take this a bit further, it means that non aligned fragments of a streamed encryption/decryption sequence should work (either in place or not).
For that matter, the previous example code can be stretched to show how it should work:
Sorry - please ignore my last message here. Figure that it was wrong, unless it's a streaming algorithm.