RE: Request for Comments about Chained-IV feature in Linux crypto framework

["Yu, Wenqian" <wenqian.yu@xxxxxxxxx>]

Format it to plaintext and resend it as HTML subpart is treated as SPAM or Outlook Virus by the system.

Thanks,
- Wenqian


From: Yu, Wenqian 
Sent: Thursday, August 3, 2017 9:13 AM
To: linux-crypto@xxxxxxxxxxxxxxx
Cc: herbert@xxxxxxxxxxxxxxxxxxx; dm-devel@xxxxxxxxxx; m-crypt@xxxxxxxx; Milan Broz <gmazyland@xxxxxxxxx>; Keating, Brian A <brian.a.keating@xxxxxxxxx>; Will, Brian <brian.will@xxxxxxxxx>; Li, Weigang <weigang.li@xxxxxxxxx>; Cabiddu, Giovanni <giovanni.cabiddu@xxxxxxxxx>; Yu, Wenqian <wenqian.yu@xxxxxxxxx>
Subject: Request for Comments about Chained-IV feature in Linux crypto framework

Hi, Herbert and all,

For saving the offload cost of symmetric cipher to hardware accelerator, we have a proposal (chained-IV) to batch multiple SG with different IV into one skcipher request, which also benefits SW implementation. The existing skcipher with SG list in crypto framework is treating all SG in the SG list as one single buffer to symmetric crypto operation with same IV.  In some use case the IV for each SG is different (e.g. dm-crypt, the IV for each sector is different). Could you please give quick comments on the below proposal before implementation?

1) Add a new flag CRYPTO_TFM_REQ_CHAINED_IV for chained IV request.

2) Reuse the existing iv in skcipher_request structure to include all the IVs for each different sg with agreement that the first block size length data of IV is for the data in first sg and so on. Same as aead_request.
struct skcipher_request {
        unsigned int cryptlen;
        u8 *iv;

        struct scatterlist *src;
        struct scatterlist *dst;

        struct crypto_async_request base;

        void *__ctx[] CRYPTO_MINALIGN_ATTR;
};

3) No API change but implementation change required inside of skcipher API to handle chained-IV support and API should inforce the same number of IV elements as that of SG elements.

Thanks,
- Wenqian