On Tue, Dec 28, 2010 at 09:29:23AM +0100, octane indice wrote: > En r?ponse ? Arno Wagner <arno@xxxxxxxxxxx> : > > The anzwer is actually no. As changed information has to be > > written to diek, an attacker can allways tell when a sector > > is changed. > > My idea is to cipher _all_ blocks by changing the salt. > > > This is a fundamental limitation of filesystem > > encryption. The only way around would be to write far more > > on each update, > > yes > > > with the expected catastrophic impact on > > performance. > > > not so much, depending on how much data you cipher. > I use files of less than 100Mbytes and cipher them. On > close, a full recipher wouldn't take long. If you do not recipher the whole device, information about what was encrypted does till leak. The information is sampled and rounded, but with a bit longer observation period a similar attack as against the original is still possible. > > > but an attacker wouldn't be able to gain any information! > > > > Wrong. The attacker could still detect the changed blocks. > > > not if I change all of them. Indeed. Which you cannot do in practice. > > > Any advice on that, or a reason why the salt is not used for > > > encrypting blocks? > > > > Because it does not help at all. Salts only help as defense > > against rainbow tables. > > > 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. > -We could change the IV: I don't see how. > Plus, both options can't afford a break (as of power loss) in the > reciphering: which key would be used after? Not a problem with careful journalling. > 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. 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 (and as Milan rightfully points out, the attacker already has repeated access), the only good way is to make it a filesystem feature and write a lot of fake data in addition. AFAIK, nobody cared enough for the, at best, marginal increase in security to actually implement such a scheme. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
