Hi Ard, The following report applies to kernel 5.3 as I am currently unable to test the latest upstream version. The CTS IV handling for cts-cbc-aes-ce and cts-cbc-aes-neon is not consistent with the C implementation for CTS such as cts(cbc-aes-ce) and cts(cbc-aes- neon). For example, assume encryption operation with the following data: iv "6CDD928D19C56A2255D1EC16CAA2CCCB" pt "2D6BFE335F45EED1C3C404CAA5CA4D41FF2B8C6DE94C706B10F1D207972DE6599C92E117E3CBF61F" key "930E9D4E65DB121E05F11A16E408AE82" When you perform one encryption operation, all 4 ciphes return: 022edfa38975b09b295e1958efde2104be1e8e70c81340adfbdf431d5c80e77b89df5997aa96af72 Now, when you leave the TFM untouched (i.e. retain the IV state) and simply set the following new pt: 6cdd928d19c56a2255d1ec16caa2cccb022edfa38975b09b295e1958efde2104be1e8e70c81340ad the C CTS implementations return 35d54eb425afe7438c5e96b61b061f04df85a322942210568c20a5e78856c79c0af021f3e0650863 But the cts-cbc-aes-ce and cts-cbc-aes-neon return a62f57efbe9d815aaf1b6c62f78a31da8ef46e5d401eaf48c261bcf889e6910abbc65c2bf26add9f My hunch is that the internal IV handling is different. I am aware that CTS does not exactly specify how the IV should look like after the encryption operation, but using the NIST reference implementation of ACVP, the C CTS implementation is considered to be OK whereas the ARM CE assembler implementation is considered to be not OK. Bottom line, feeding plaintext in chunks into the ARM CE assembler implementation will yield a different output than the C implementation. Ciao Stephan
