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: <82248c13-42fe-b598-0cd7-68e5db0b51be@gmail.com>
Date:   Wed, 18 Jul 2018 19:17:45 +0200
From:   Milan Broz <gmazyland@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Xiongfeng Wang <wangxiongfeng2@...wei.com>, agk@...hat.com,
        snitzer@...hat.com, herbert@...dor.apana.org.au,
        dm-devel@...hat.com, linux-kernel@...r.kernel.org, arnd@...db.de,
        jonathan.cameron@...wei.com
Subject: Re: [PATCH 4/5] crypto: Add IV generation templates

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.
> 
>> The TCW,LMK  IVs generator make sense only for dm-crypt 
>> for compatible old disk encryption mappings.
> 
>> I strongly disagree to move this outside of dm-crypt.
> 
>> Sorry, the last discussion was that it remains inside dm-crypt
>> and it will be only registered through crypto API.
> 
> Sorry, I'm partly to blame for this in that I asked Xiongfeng to pick up
> Binoy Jayan's old patch set.  I seem to have missed that particular part
> of the discussion and so haven't forwarded it on to him - do you have a
> link, I can't seem to see it in my local archives of the prior
> discussions but they might not be complete?

I think the last iteration was this patch
https://lore.kernel.org/lkml/1498106510-19793-2-git-send-email-binoy.jayan@linaro.org/

But I have still some questions, because I really do not understand
the real reason for this patchset.
For now, it adds a lot of complexity for ... what?

1) If the reason is to make cryptoapi to include IV algorithms, I think we should
focus on universal algorithms (sequential aka plain64 in dmcrypt) as used
in XTS mode. ESSIV is intended for CBC mode only and I think general
consensus today is that XTS mode is preferred to CBC (despite it known problems).
But I see ESSIV used elsewhere, so maybe it makes sense to export this one as well.

But definitely not other internal IVs - some IV generators inside dm-crypt
(namely TCW and LMK) do much more that IV - they modify encryption mode.
This was a hack to support some FDE encryption modes (old Truecrypt and loopAES)
and that should not spread outside dm-crypt (and blame me for this code hacks :).

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?

I added 4k sector support in dmcrypt and IMO this helps much more
than some hw IV accelerations (AFAIK is is already used in some mainframe
accelerators this way because of performance).

Milan