Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1589814

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

From Milan Broz <gmazyland@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
Date 2017-02-28 22:40 +0100
Message-ID <tfXF0-1ys-13@gated-at.bofh.it> (permalink)
References <t8blL-1E3-5@gated-at.bofh.it> <t8v18-5P4-7@gated-at.bofh.it> <tdyrn-5MV-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 02/22/2017 07:12 AM, Binoy Jayan wrote:
> 
> I was wondering if this is near to be ready for submission (apart from
> the testmgr.c
> changes) or I need to make some changes to make it similar to the IPSec offload?

I just tried this and except it registers the IV for every new device again, it works...
(After a while you have many duplicate entries in /proc/crypto.)

But I would like to see some summary why such a big patch is needed in the first place.
(During an internal discussions seems that people are already lost in mails and
patches here, so Ondra promised me to send some summary mail soon here.)

IIRC the first initial problem was dmcrypt performance on some embedded
crypto processors that are not able to cope with small crypto requests effectively.

Do you have some real performance numbers that proves that such a patch is adequate?

I would really like to see the performance issue fixed but I am really not sure
this approach works for everyone. It would be better to avoid repeating this exercise later.
IIRC Ondra's "bulk" mode, despite rejected, shows that there is a potential
to speedup things even for crypt drivers that do not support own IV generators.

I like the patch is now contained inside dmcrypt, but it still exposes IVs that
are designed just for old, insecure, compatibility-only containers.

I really do not think every compatible crap must be accessible through crypto API.
(I wrote the dmcrypt lrw and tcw compatibility IVs and I would never do that this way
if I know it is accessible outside of dmcrypt internals...)
Even the ESSIV is something that was born to fix predictive IVs (CBC watermarking
attacks) for disk encryption only, no reason to expose it outside of disk encryption.

Milan

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Binoy Jayan <binoy.jayan@linaro.org> - 2017-02-22 07:20 +0100
  Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-02-28 22:40 +0100
    Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-01 09:50 +0100
      Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-03-01 10:40 +0100
        Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-01 14:00 +0100
          Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-03-01 14:10 +0100
            Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-03-01 16:40 +0100
              Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-06 15:40 +0100
          Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Ondrej Mosnacek <omosnace@redhat.com> - 2017-03-01 14:30 +0100
            Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-02 15:10 +0100

csiph-web