On 05/19/2011 10:01 AM, Yves-Alexis Perez wrote: > On jeu., 2011-05-19 at 09:05 +0200, Milan Broz wrote: >> On 05/18/2011 11:53 PM, Yves-Alexis Perez wrote: >>> If you read the paper, you'll noticed there's nothing to change to >>> dm-crypt, as the cypher is registered in the Crypto-API, it can be used >>> directly. >> >> TBH dmcrypt keeps its own copy of key (because key it is still part >> of the device-mapper mapping table so it must be available for >> status commands). > > In that case it'll be the âdummyâ key. The logic now works that table line received from dmcrypt is directly usable - cryptsetup uses that e.g. for resize. Replacing the key with zeroes or something will break this. (Note that tools for scanning memory scan for pre-calculated AES key, not for this "plain hexa string" dmcrypt pattern, I had some simple modification for testing luksSuspend - which must wipe all these keys. I had also idea to build this scanner as directly grub loadable image - to demonstrate that most of distributions are not able to properly shutdown system if root fs running from encrypted disk and after "clean" reboot key is still in memory. Finally, dracut/systemd has already idea of "shutdown pivot_root" which allows decomposing of root devices properly - thus shutting the dmcrypt properly and wiping the key.) >> So there are some changes needed but basically technicaly unrelated >> to that patch. >> (This will hopefully change with new mapping table format soon.) > > Needed for what? You mean new table format? Currently the table format is fixed (and parsing hardcoded in various tools) so cannot be extented. I have several reasons to define new format (of course it will be used only with new tools, is still must support old format). - encryption key, once set, should be not easily accessible from the outside of module, (FIPS is even stricter here btw). So I want to set encryption key only though message and remove it from new mapping table. (This even allows other source for key - like internal kernel keyring or so.) (See "dmsetup table --showkeys" here for demonstration of problem.) The mechanism is already in place for luksResume command. - any extension for table like optional discard support or online reencryption helpers need aditional parameters - and the table is not extensible (other DM targets use "parameter" count field so parameter count is not fixed but not dmcrypt) ... etc. >> >> Anyway, it must be accepted into kernel crypto layer first. > > I'm not even sure it'll be submitted though. So it is just academic exercise for conferences? >> IMHO I think that without strong hw support these implementation >> will have some problems but it is good that someone works on such >> things. >> (E.g. how it works if it is not bare hw but virtualized system?) > > For the AES-NI one, if the hypervisor supports it (they tested on KVM) > yes (though the vm registers are stored in the host ram anyway). Yes, that was my point. (AES-NI works for guests but bare hw has of course limited hw resources.) > If you're interested, I found that the two papers were quite clear and > quick to read, so it might be a good idea to read them. Sure, I will read them. Thanks, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
