On 01/11/2011 05:35 PM, Richard wrote: > On Tue, Jan 11, 2011 at 11:31:37AM +0100, Milan Broz wrote: >> What is not safe is suspend to RAM. Maybe someone should start to use >> luksSuspend to at least clear encryption key from memory but it is not >> as easy implement as it seems:) > > surely luksSuspend would make it safer but still complete RAM would be left > unprotected which can be a lot of information. Did anyone look inot encrypting > RAM before suspend? That's not probably easily done and I think it is not worth to try - simple use hibernation here. (Of course if there is support in hw it is easy.) > As it is now it is also not trivialy broken - getting the filesystems would > involve breaking screen saver locking, breaking in through network or other > interfaces or freezing the computer to retrieve and examine ramchips. Just reset and boot memory dumper, chances that you get the encryption key are very high (memory dumper uses just few pages and BIOSes do not wipes memory during reboot). It is quite easy. (of course you can disable USB/PXE/CDROM boot etc but in principle it is still problem.) > seems dm or something else is slow enough that id does not matter at all. LVM (linear mapping) will not slow down it, with comparison to encryption time for remapping is completely insignificant. If you have some strange numbers, report a bug and add your configuration description, but I know how the kernel works - there is really nothing complex on this path. Usually problem is with some misaligned devices - but this can happen even with partitions. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
