Re: [dm-crypt] using a salt for encrypting blocks

[Arno Wagner <arno@wagner.name>]

On Tue, Dec 28, 2010 at 09:29:23AM +0100, octane indice wrote:
> En r?ponse ? Arno Wagner <arno@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,
> 
> 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@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