For algorithms that implement IV generators before the crypto ops,
the IV needed for decryption is initially located in req->src
scatterlist, not in req->iv.
aead_givdecrypt() is updated to put the IV in place.
Cc: <stable@xxxxxxxxxxxxxxx> # 4.3+
Fixes: 479bcc7c5b9e ("crypto: caam - Convert authenc to new AEAD interface")
Suggested-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Horia Geantă <horia.geanta@xxxxxxx>
---
Herbert, as you suggested, aead_givdecrypt() is now setting the IV.
In terms of optimizations, would it be safe to assume all "geniv" authenc
algorithms - {echainiv, seqiv}(authenc) - get assoc,iv,ciphertext in
req->src for decryption?
The idea would be to avoid copying IV into req->iv and instruct
the crypto engine to access it directly from req->src scatterlist.
drivers/crypto/caam/caamalg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 6dc597126b79..78be2bea1273 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2545,6 +2545,7 @@ static int aead_givdecrypt(struct aead_request *req)
if (req->cryptlen < ivsize)
return -EINVAL;
+ scatterwalk_map_and_copy(req->iv, req->src, req->assoclen, ivsize, 0);
req->cryptlen -= ivsize;
req->assoclen += ivsize;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
