On 12/29/2009 10:21 AM, Richard Zidlicky wrote: > On Mon, Dec 28, 2009 at 08:37:43PM +0100, Milan Broz wrote:
> While we are at it - are you aware of any documentation of the "mainline" > dm-crypt > implementation? I have not seen anything, much less any explanation if it has > improved > any since the ancient watermarking attack. > > http://luks.endorphin.org/ is down, http://www.saout.de/misc/dm-crypt/ has > plenty of > information but I am not sure if it is up to date.. well if it is than it > seems default > dm-crypt still has more or less snake oil quality encryption. ok, I should probably add some info, probably to new cryptsetup pages http://code.google.com/p/cryptsetup/ and kernel to documentation, if needed. - the watermarking attack is not possible with introducing ESSIV long time ago (essiv default for LUKS formatted devices by cryptsetup - for several years) - I prefer using XTS mode, but user can use whatever is supported in kernel - AFAIK there is no known problem with dm-crypt (stability or security) when properly configured (you can of course use old vulnerable IV mode if you want). (And many distributions and uses dm-crypt/LUKS based full disk encryption currently, also Truecrypt uses dm-crypt as backend on Linux for new containers.) (If you think about coldboot or something similar - dm-crypt provides functions to temporarily freeze device and empty keys and I also added support for this to cryptsetup. So the controlled suspend/resume to RAM can ask for LUKS passphrase and unlock master key, preventing active encryption keys in RAM. Of course this do not apply to if the shutdown is not controlled, but that's common problem of all these implementations.) If you know about some problem in dm-crypt, just let me know (or write to dm-crypt mailing list). Milan -- mb...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
