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] Encrypted Btrfs RAID1
Date: Wed, 11 Sep 2013 20:24:12 +0200	[thread overview]
Message-ID: <20130911182411.GA29506@tansi.org> (raw)
In-Reply-To: <5230B2B8.9060604@gmx.de>

On Wed, Sep 11, 2013 at 08:13:12PM +0200, ax487 wrote:
> Hello all,
> 
> I have been using LUKS for quite some time now to encrypt block devices.
> Up to now I have always used the setup RAID1 -> Encryption -> LVM2 ->
> filesystems.
> Now however I want to create an encrypted Btrfs RAID1. The problem is
> that a RAID based on Btrfs is not based on block devices. What I would
> need is to encrypt two different partitions and then use their decrypted
> counterparts as basis for the RAID. The problem is that I really don't
> want to add my pass phrase multiple times and I don't like key files. I
> realize that the 'reuse key' problem is a long standing issue:
> 
> https://bbs.archlinux.org/viewtopic.php?id=117152
> https://bugzilla.redhat.com/show_bug.cgi?id=446567
> https://www.martineve.com/2012/11/02/luks-encrypting-multiple-partitions-on-debianubuntu-with-a-single-passphrase/
> 
> However I did not find a solution anywhere.
> Could you tell me how to setup my system to make things work the way I
> intend to?

Easy answer: Don't use Btrfs as long as it is not finished (i.e.
does not implement encryption). If these people think they can 
integrate multiple storage layers, they should at least have the
most common in there and that does include encryption.

More complicated answer: There is no pre-packaged solution.
You could do different things, e.g. make one parition LUKS
and the other plain dm-crypt with a key derived somehow from 
the LUKS master key.

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

  reply	other threads:[~2013-09-11 18:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11 18:13 [dm-crypt] Encrypted Btrfs RAID1 ax487
2013-09-11 18:24 ` Arno Wagner [this message]
2013-09-11 20:39   ` ax487
2013-09-11 23:19     ` 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=20130911182411.GA29506@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.