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 doable. 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. Regards, -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
