| Message ID | 20200519190211.76855-2-ardb@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC/RFT,1/2] crypto: arm64/aes - align output IV with generic CBC-CTS driver | expand |
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
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@kernel.org> --- arch/arm64/crypto/aes-modes.S | 2 ++ 1 file changed, 2 insertions(+)