DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS and LVM
Date: Sat, 19 Feb 2011 15:52:23 +0100	[thread overview]
Message-ID: <20110219145223.GA1883@tansi.org> (raw)
In-Reply-To: <ijoifg$8ns$1@dough.gmane.org>

On Sun, Feb 20, 2011 at 01:01:18AM +1100, Eric Bauman wrote:
> On 19/02/2011, Arno Wagner wrote:
>> Also, knowing were the encrypted
>> data is does not help the attacker, unless he/she can repeatedly
>> access the computer. In that case, all is luikely lost anyways.

> Forgive my ignorance, some sources say suggest randomising the disk  
> before creating a container so that it's not possible to determine what  
> is data and what is garbage. So I assumed the visible LVM header would  
> reduce some of this benefit. Is there merit to this disk randomisation  
> or does it just sound good but do nothing, spread by misinformed people  
> such as myself? :)

There is one merits to randomisation with crytographically
strong randomness: An attacker cannto tell how much data is
in a crypto container and where exactly it is. It is conceivable
that without ramdomisation an attacker could guess the filesystem,
the size of some files and the overall data size. That is typically
hard to do, limited to 512 byte (sector size) or 4096 byte 
(filesystem block size) precision and the information gained 
in the worst case is not a lot. Side note: The LVM header only 
describes the size of the container, not where exactly the data 
is. Container-size is typically not information that helps the 
attacker at all.

There is a second benefit to overwriting: You make sure no old data
is retained.

So, while not absolutely critical, it is good practice to
overwrite with crypto-randomness. Except in special cases,
you do not need to obfuscate the size of partitions or
containers, i.e. the attacker can have access to LVM/LUKS/RAID
headers and superblocks without negative effect on security.

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 

  reply	other threads:[~2011-02-19 14:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18 16:39 [dm-crypt] LUKS and LVM Eric Bauman
2011-02-18 17:33 ` Arno Wagner
2011-02-18 17:53   ` Eric Bauman
2011-02-18 19:57     ` Milan Broz
2011-02-18 20:07     ` Arno Wagner
2011-02-19 14:01       ` Eric Bauman
2011-02-19 14:52         ` Arno Wagner [this message]
2011-02-19 16:46       ` Nicolas Bock
2011-02-19 17:10         ` Milan Broz
2011-02-19 18:17           ` Jonas Meurer
2011-02-19 19:11             ` Nicolas Bock
2011-02-19 19:10           ` Arno Wagner
2011-02-19 19:08         ` Arno Wagner
2011-02-19 19:12           ` Nicolas Bock

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=20110219145223.GA1883@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox