Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Milan Broz <mbroz@redhat.com>]

On 07/27/2010 05:45 PM, Mario 'BitKoenig' Holbe wrote:

> For example, if you like to protect against disk theft your attack model
> doesn't include snapshots. If you like to protect against spying your
> attack model very likely includes snapshots.

Well, the discussion here is about encryption modes etc - I guess probably
one of the stronger part of the chain.

But you mention attack models where you can do snapshots or spying...

- in most situations it means that attacker have physical access to machine
There are many other attacks then which are simpler (memory scan, installing
hw keylogger, installing malware - in all levels from bios to kernel, various
power measures, injecting intentional hw malfunctions etc)

- if attacker have unprivileged account on machine with running encryption,
there are cache attacks on aes implementation

... just examples, threat model depends on real usecase

So, knowledge of encryption mode security and proper use limits is surely
important but we must analyse the whole system and its connections outside.
And usually there are weaker parts elsewhere (...which are also people obviously
http://xkcd.com/538/ :)

If possible encryption mode scares you, you can still use stacking
of various ciphers - like Truecrypt does. If one is broken, there is still
another level.
It is easy to do it with cryptsetup also (IOW LUKS over LUKS).

When mentioning TC - their requirements and precautions applies to cryptsetup
as well http://www.truecrypt.org/docs/?s=security-requirements-and-precautions
...


> Btw... Arno: w.r.t. Gutmann and off-track-forensics: I usually avoid
> replying just to say "Please mind the smiley", but here is a good place
> to mention it :) No, I don't believe in off-track-forensics on todays
> hard disks, but cryptsetup does: luks/keymanage.c:wipe().

(Neither me :), it doesn't work for SSD/Flash drives at all,
but once it is there why remove it? It should not harm:-)

>> Is there any way to avoid this? Or only to re-encode the device
>> regularly with another key
> 
> Yep that's your way to go :)
> 
>> (btw: is it with LUKS possible to do this on the fly?)?
> Nope. Not yet. It's possible to code it, though :)

Maybe one day it will be there but probably as part of LVM
(which will use libcryptsetup for key management for encrypted
logical volumes).

It is possible to encode some simple function to reencode disk
in-place. But I would like to have something better, LVM
already provides most of infrastructure for such block device
operations. (beware: I am also lvm developer:)

Milan