En réponse à Arno Wagner <arno@xxxxxxxxxxx> : > > not if I change all of them. > > Indeed. Which you cannot do in practice. > By changing the salt, yes. I understand that's a huge performance issue on closing the device, but it's acceptable in regard of the privacy gain. > > In this situation it helps in order to change the ciphered > > version even if we don't change the clear. > > -We could change the master key: impossible in practice. > > Not harder than changing the salt, actually. You do have > to recrypt the whole device anyways for this to be secure, > so changing the master key is entrierly possible. > No. The problem lies when you trans-cipher the device from the old master key to the new master key. You begin to transcipher to the half of the device, then you encounter a power loss of your laptop. The next boot, you lost a lot of things. Either the new master key is saved, then you read only what has been transciphered, or the old master key, and you can read the other half. And if you have both keys, you can't determine which one has to be used for a specific block, or you must track what's has been transciphered which seems to be harder to implement than just changing the salt. Plus, but I didn't want to say it, you can imagine random block changes when using the device. Just check when the system is not busy, check an unused block, recipher it. > > If we use a salt, we can always decipher, even if a break > > occurs while reciphering; at last, only one block could be > > unreadable. > > If thet one block holds critical meta-information, the > damage can be extreme. > Yes but it's allways the situation when a disk is hard-stop by a power loss. > Sorry, this is not the way to go. And you are not the > first with this (or a similar) idea as well. If you really > want to prevent visibility of what was changed in the > encrypted device yes > (and as Milan rightfully points out, the > attacker already has repeated access), Yes, I think that's unavoidable. You have to consider that an attacker has repeated access to your computer. > the only good way > is to make it a filesystem feature and write a lot > of fake data in addition. ok. but it would be tight to a filesystem. Working with the block level could be used with anything. > AFAIK, nobody cared enough > for the, at best, marginal increase in security to > actually implement such a scheme. > ok. I understand, but I disagree with the "marginal" impact :-) thanks > _______________________________________________ Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
