From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] using a salt for encrypting blocks
Date: Mon, 27 Dec 2010 22:52:00 +0100 [thread overview]
Message-ID: <20101227215200.GA6681@tansi.org> (raw)
In-Reply-To: <1293466212.4d18ba64b28dc@www.inmano.com>
On Mon, Dec 27, 2010 at 05:10:12PM +0100, octane indice wrote:
> Hello
>
> I'm working with dm-crypt.
> Basically, we have a key, which I call Master key, which is used to cipher
> blocks (or sectors).
> This master key is wrapped with another keys, the 8 slots, this is not the
> point here.
>
> Each block is then ciphered. the cipher mode is CBC, and each block has a
> different IV. Today, the ESSIV is used, which means that the IV is derived
> by the sector number and a hash of the master key. I'm OK with that.
>
> So, this means that the same block of the same plaintext is ciphered the
> same way. So if a file is unchanged, then the ciphered is unchanged.
>
> Which means that an attacker could track the change of the ciphered blocks
> and gain some (very little) knowledge, as the size of the document being
> added to a encrypted partition.
>
> My question is: can we avoid this? The answer is yes, we just have to use a
> salt.
> For example, for 512byte blocks, we could use 16bytes of salt for each block.
The anzwer is actually no. As changed information has to be
written to diek, an attacker can allways tell when a sector
is changed. 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.
> Which means that one block each 32 blocks stores the salt of the other
> blocks. This way, it's possible to update all blocks and cipher them. Same
> data, cipher is different.
> I think we could have
> -performance issue,
> -decrease the size of 'usable' part of disk, 3% is used to store the salt,
> which is acceptable.
>
> but an attacker wouldn't be able to gain any information!
Wrong. The attacker could still detect the changed blocks.
> 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.
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
next prev parent reply other threads:[~2010-12-27 21:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 16:10 [dm-crypt] using a salt for encrypting blocks octane indice
2010-12-27 21:52 ` Arno Wagner [this message]
2010-12-28 8:29 ` octane indice
2010-12-28 11:03 ` Milan Broz
2010-12-28 14:05 ` octane indice
2010-12-28 19:49 ` Milan Broz
2010-12-30 10:11 ` octane indice
2010-12-30 12:27 ` Arno Wagner
2010-12-28 13:32 ` Arno Wagner
2010-12-28 14:23 ` octane indice
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101227215200.GA6681@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.