All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Cascading two plain dm-crypt volumes
Date: Fri, 29 Nov 2013 01:27:45 +0100	[thread overview]
Message-ID: <20131129002745.GA6415@tansi.org> (raw)
In-Reply-To: <4b257a0455c2ff44b6c488df576b9764@www.mighty.co.za>

Hi,

On Fri, Nov 29, 2013 at 00:32:30 CET, anderson jackson wrote:
> Hello, 
> 
> I have a small question regarding luks and plain dm-crypt, and I am unsure
> what to use. 
> 
> I feel that the advantages provided by Luks obviously offers extra
> security compared to plain, however I feel uneasy about the obviousness of
> the fact that the drive is encrypted.

That issue question crops up from time to time. 
See also FAQ Item 5.18.

> Mainly because a disk with just random data could have been wiped instead
> of encrypted.  I would like the extra security provided by luks without it
> being obvious that the disk is encrypted. To combat this I was thinking
> about doing a cascade of two identical ciphers in plain mode, in this case
> AES because the AES-NI acceleration will severely limit the performance
> penalty of cascading two ciphers, I had the following setup in mind:

The problem you now have is that you asked about this here. If you
do such a set-up and somebody (law enforcement, e.g.) finds a
"randomized" partition, they can just use that as argumentation
why you are likely hiding an encrypted partition. Remember that
law enforcement is an authoritarian concept and they do not care 
about right or wrong, but desire that you bow to their wishes. So 
if they have enough to hold you, they will just imprison you for 
a while until you hand them the key. If they do not, you can just 
refuse to give out the LUKS key. For LUKS, you can always claim 
that it was an old experiment and you do not know the passphrase
anymore. Gives about as much protection. 

Same applies in even worse form if somebody extorts you or 
kidnaps you together with your disk. 

> first step: cryptsetup –-cipher=aes-xts-plain –-offset=0 –-key-size=512
> open –-type=plain /dev/sdx cascade1, with the first independend password.
> Second step: cryptsetup –-cipher=aes-xts-plain –-offset=0 –-key-size=512
> open –-type=plain /dev/mapper/cascade1 cascade2, with the second independed
> unrelated password.
> Third step: nwipe --rounds=1 --noblank --prng=twister --method=random
> /dev/mapper/cascade2, this will fill the last block device with random data to
> completely fill up the entire disk. 
> Fourth step: format the last block device with ext4.
> 
> My theory then is, that even when an attacker finds the first passwords, he
> will never know he has because the result will be random just as with a wrong
> password. 

With the fist password correct, you see the LUKS header.

> In fact all possible passwords will result in random data. The attacker
> has no way of knowing if there are cascades and how many.  Am I right to
> come to this conclusion or should I stick with luks and deal with it being
> an obvious encrypted disk?

Stick with LUKS and know it is obvious (and prevent the situation
where you may have to lie to the attacker "it is not an encrypted
partition", and may later have to retract that lie resulting in
additional problems). Refuse to provide the passphrase before
talking to an attorney for "legal" attacks or plain refuse for 
others. 

Alternatively, use a plain dm-crypt container, do the random wiping
as well, and use a better passphrase. See FAQ Item 5.1 for my 
current recomendations for LUKS and plain.

In both cases, make sure your attacker cannot brute-force the
passphrase. At this time, I would recommend using at least
100 bit of entropy for both LUKS and plain if you want to be
sure. 

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

  parent reply	other threads:[~2013-11-29  0:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 23:32 [dm-crypt] Cascading two plain dm-crypt volumes anderson jackson
     [not found] ` <CAMw1ynShpDpGVNWZGfHNkvApbiMadidiBkVStDsL9AUkbZ+B9w@mail.gmail.com>
2013-11-29  0:08   ` Claudio Moretti
2013-11-29  0:32     ` Arno Wagner
2013-11-29  0:49       ` anderson jackson
2013-11-29  1:03         ` Arno Wagner
2013-11-29  1:31           ` anderson jackson
2013-11-29  5:06             ` Arno Wagner
2013-11-29  0:27 ` Arno Wagner [this message]
2013-11-29 10:55 ` Matthias Schniedermeyer
2013-11-29 16:53   ` Arno Wagner

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=20131129002745.GA6415@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.