Hi Herbert, On 2 January 2017 at 12:23, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote: > > Right. The actual number of underlying tfms that do the work > won't change compared to the status quo. We're just structuring > it such that if the overall scheme is supported by the hardware > then we can feed more than one sector at a time to it. I was thinking of continuing to have the iv generation algorithms as template ciphers instead of regular 'skcipher' as it is easier to inherit the parameters from the underlying cipher (e.g. aes) like cra_blocksize, cra_alignmask, ivsize, chunksize etc. Usually, the underlying cipher for the template ciphers are instantiated in the following function: skcipher_instance:skcipher_alg:init() Since the number of such cipher instances depend on the key count, which is not known at the time of creation of the cipher (it's passed to as an argument to the setkey api), the creation of those have to be delayed until the setkey operation of the template cipher. But as Mark pointed out, the users of this cipher may get confused if the creation of the underlying cipher fails while trying to do a 'setkey' on the template cipher. I was wondering if I can create a single instance of the cipher and assign it to tfms[0] and allocate the remaining instances when the setkey operation is called later with the encoded key_count so that errors during cipher creation are uncovered earlier. Thanks, Binoy -- 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
