[dm-crypt] The future of disk encryption with LUKS2

Yves-Alexis Perez corsac at debian.org
Fri Feb 5 17:50:14 CET 2016

On ven., 2016-02-05 at 16:24 +0100, Arno Wagner wrote:
> Then why are you asking about integrity protection on a list
> dedicated to a block-layer encryption system? That does not make
> any sense. If you state things that do not make sense then I
> will point that out, because there is a real possibility that
> your reasoning process (I am not implying there was none) was 
> flawed. 

Because integrity protection *does* make sense on block layer encryption? The
fact that you don't have a 1:1 mapping is indeed an issue, and that's why I
was asking in the context of the LUKS2 thread (where supposedly new ideas
could be thrown), because solving the involved challenges would be useful in
the context of dm-crypt. I think. You could store all ICV in a specific place
in the block device, or have one block of ICVs every once in a while, or
something else. It'd involve some clever calculation indeed but it might be

But I can perfectly understand if it's not something which interest developers
here, and I can perfectly take “no” as an answer :)
> > > And second, who says anything abot the "evil maid" changing
> > > things in the encrypted container?
>> > I'm not following you here.
> Attacks on hardware, replacement of the disk with something that
> attacks the boot process, Firewire, USB, etc. vulnerabilities, 
> changes in non-encrypted areas, etc.

This is about your external disk drive or usb where you put data on it. This
is not about boot integrity or something, really.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20160205/8b13e3b5/attachment.asc>

More information about the dm-crypt mailing list