On 11/17/2016 12:01 PM, Michael Weiser wrote:
> Hi Horia,
> On Thu, Nov 17, 2016 at 10:18:50AM +0200, Horia Geant?? wrote:
>> ablkcipher API is not completely removed from kernels <= v4.9.
>> Thus it's still valid to use ablkcipher algorithms.
> I was under the impression that skcipher is just a unified API meant to
> give a common way of accessing synchronous and asynchronous block
> ciphers. That's why I assumed it to be a drop-in replacement in our
> case.
Yes, the intent is to replace (a)blkcipher with skcipher, however the
conversion is not over yet.

> This commit spells it out clearly IMO:
> https://github.com/torvalds/linux/commit/ba871e1d299154953dcee23590c0316283897261
I think the documentation update was either too early or targeted
towards discouraging the proliferation of ablkcipher.

> Can you point me to an implementor that somehow registers an
> ansynchronous block cipher that's not accessible via skcipher?
caam driver is what triggered this patch:

On the linux-crypto mailing list you can see there is on-going work:
crypto: skcipher - skcipher algorithm conversion part 3

and a part 4 (converting existing drivers) will surely follow.

>> Fix the case when implementers register ablkcipher algorithms
>> and cryptodev casts them to skcipher without checking their type.
> So is your patch meant as a stop-gap measure for releases ablk/skcipher
> hybrid kernels until all implementors have made their ciphers available
> via skcipher as well or did I get it wrong and (part of) the ablkcipher
> API will stick around indefinitely?
First option - "hybrid" kernels.


Cryptodev-linux-devel mailing list

Reply via email to