[dm-crypt] using a salt for encrypting blocks
arno at wagner.name
Tue Dec 28 14:32:08 CET 2010
On Tue, Dec 28, 2010 at 09:29:23AM +0100, octane indice wrote:
> En r?ponse ? Arno Wagner <arno at wagner.name> :
> > 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,
> > 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
> > > 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 Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at wagner.name
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
More information about the dm-crypt