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@vger.kernel.org
Cc: herb...@gondor.apana.org.au; dm-de...@redhat.com; m-cr...@saout.de; Milan
Broz <gmazyl...@gmail.com>; Keating, Brian A <brian.a.keat...@intel.com>; Will,
Brian <brian.w...@intel.com>; Li, Weigang <weigang...@intel.com>; Cabiddu,
Giovanni <giovanni.cabi...@intel.com>; Yu, Wenqian <wenqian...@intel.com>
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
