Re: [PATCH] crypto: generic/cts - fix regression in iv handling

On 17 January 2017 at 09:11, Herbert Xu [off-list ref] wrote:

On Mon, Jan 16, 2017 at 09:16:35AM +0000, Ard Biesheuvel wrote:

quoted

Since the skcipher conversion in commit 0605c41cc53c ("crypto:
cts - Convert to skcipher"), the cts code tacitly assumes that
the underlying CBC encryption transform performed on the first
part of the plaintext returns an IV in req->iv that is suitable
for encrypting the final bit.

While this is usually the case, it is not mandated by the API, and
given that the CTS code already accesses the ciphertext scatterlist
to retrieve those bytes, we can simply copy them into req->iv before
proceeding.

Ugh while there are some legacy drivers that break this is certainly
part of the API.

Which underlying CBC implementation is breaking this?

arch/arm64/crypto/aes-modes.S does not return the IV back to the
caller, so cts(cbc-aes-ce) is currently broken.

So to be clear, it is part of the API that after calling
crypto_skcipher_encrypt(req), and completing the request, req->iv
should contain a value that could potentially be used to encrypt
additional data? That sounds highly specific to CBC (e.g., this could
never work with XTS, since the tweak generation is only performed
once), so it does not make sense for skciphers in general. For
instance, drivers for h/w peripherals that never need to map the data
to begin with (since they only pass the physical addresses to the
hardware) will need to explicitly map the destination buffer to
retrieve those bytes, on the off chance that the transform may be
wrapped by CTS.