linux-kernel - Re: [PATCH 4/5] crypto: Add IV generation templates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2oubqRKg1tnoG6CsmUs-U5Ab6q5rwpfg08PRNJLhEjEw@mail.gmail.com>
Date:   Thu, 19 Jul 2018 10:50:12 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Xiongfeng Wang <wangxiongfeng2@...wei.com>
Cc:     Milan Broz <gmazyland@...il.com>, Mark Brown <broonie@...nel.org>,
        Alasdair Kergon <agk@...hat.com>,
        Mike Snitzer <snitzer@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>, dm-devel@...hat.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonathan Cameron <jonathan.cameron@...wei.com>
Subject: Re: [PATCH 4/5] crypto: Add IV generation templates

On Thu, Jul 19, 2018 at 3:46 AM, Xiongfeng Wang
<wangxiongfeng2@...wei.com> wrote:
> Hi,
>
> On 2018/7/19 1:17, Milan Broz wrote:
>> On 18/07/18 18:46, Mark Brown wrote:
>>> On Wed, Jul 18, 2018 at 10:16:05AM +0200, Milan Broz wrote:
>>>
>>>> So we are here again and moving INTERNAL dm-crypt functionality into
>>>> cryptoapi.
>>
>> 2) If the reason is performance, please provide numbers with the patch.
>> What I see now is that the performance is almost the same. So why you are doing it?
>> Any real hw that benefits from it?
>
> Because the internal implementation of the IV template 'benbi()' is still
> dividing the whole bio into sectors, so the performance is almost the same.
> The purpose of this patch is to let dm-crypt rely on the new algorithm 'aes-cbc-benbi'
> and pass the whole bio to the new algorithm.
> And then if the hardware driver implements this new algorithm, it can get the data of
> the bio at one time, and return the processed data at one time.
> I think it will decrease the overhead of passing each sector alternatively.
> But the hardware need to implement the new algorithm if it want to benefit from this.

There seems to be some support for at least essiv(aes) in
drivers/crypto/ccree/cc_cipher.c, is that compatible with your essiv(*)
template, or is that something else?

       Arnd