The generic CTS chaining mode wraps the CBC mode driver in a way that
results in the IV buffer referenced by the skcipher request to be
updated with the last block of ciphertext. The arm64 implementation
deviates from this, given that CTS itself does not specify the concept
of an output IV, or how it should be generated, and so it was assumed
that the output IV does not matter.
However, Stephan reports that code exists that relies on this behavior,
and that there is even a NIST validation tool that flags it as
non-compliant [citation needed. Stephan?]
So let's align with the generic implementation here, and return the
penultimate block of ciphertext as the output IV.
Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
---
arch/arm64/crypto/aes-modes.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index cf618d8f6cec..80832464df50 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -275,6 +275,7 @@ AES_FUNC_START(aes_cbc_cts_encrypt)
add x4, x0, x4
st1 {v0.16b}, [x4] /* overlapping stores */
st1 {v1.16b}, [x0]
+ st1 {v1.16b}, [x5]
ret
AES_FUNC_END(aes_cbc_cts_encrypt)
@@ -291,6 +292,7 @@ AES_FUNC_START(aes_cbc_cts_decrypt)
ld1 {v1.16b}, [x1]
ld1 {v5.16b}, [x5] /* get iv */
+ st1 {v0.16b}, [x5]
dec_prepare w3, x2, x6
decrypt_block v0, w3, x2, x6, w7
--
2.20.1
