[dm-crypt] Encrypt all partitions with dm-crypt

[dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

Hello,

I'd like to encrypt all partitions (or most of them) with plain dm-crypt.

Here is my partition scheme:

1. /dev/sda1 ext3 (I want to install Parabola here.)
2. /dev/sda2 swap
3. /dev/sda3 ext3 gNewSense

I can't boot from CD or USB that's why I'm going to use the third partition.

I'd like to format the first two partitions and encrypt them with
plain dm-crypt.
After that I will install Parabola [1] on the first partition. Will this work?

I'm not sure because my bootloader (PMON) uses the first partition to
store its conf file.

And how will this work from user's perspective? Will I be prompted for
a passphrase?

Should I use a more complicated scheme (with /boot)?

[1] Here is the installation guide:
https://wiki.parabolagnulinux.org/MIPS_Installation

Thanks

P.S. I haven't decided what to do with the third partition yet. Maybe
I'll erase and encrypt it later.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Wed, Aug 22, 2012 at 04:10:01PM +0400, Stayvoid wrote:
> Hello,
> 
> I'd like to encrypt all partitions (or most of them) with plain dm-crypt.
> 
> Here is my partition scheme:
> 
> 1. /dev/sda1 ext3 (I want to install Parabola here.)
> 2. /dev/sda2 swap
> 3. /dev/sda3 ext3 gNewSense
> 
> I can't boot from CD or USB that's why I'm going to use the third partition.
> 
> I'd like to format the first two partitions and encrypt them with
> plain dm-crypt.
> After that I will install Parabola [1] on the first partition. Will this work?
> 
> I'm not sure because my bootloader (PMON) uses the first partition to
> store its conf file.

And there you have answered your question already: No. 
What you can do is create a small (e.g. 100MB) partition for the
bootloader that is not encrypted.

> And how will this work from user's perspective? Will I be prompted for
> a passphrase?

Why should you be? Unless your distribution has a mechanism
that does this (out of scope for cryptsetup), you need to
map and mount it manually. I have no idea what your particular
distro of choice can or cannot do here, but you need to lok
in its documentation to find out, not here. cryptsetup is just a
tool with similarities to "mount", not an integrated system
encryption solution.

> Should I use a more complicated scheme (with /boot)?
> 
> [1] Here is the installation guide:
> https://wiki.parabolagnulinux.org/MIPS_Installation
> 
> Thanks
> 
> P.S. I haven't decided what to do with the third partition yet. Maybe
> I'll erase and encrypt it later.

You need if for booting. Unless your distro has an initrd that
can mount encrypted volumes. See docu of your distro.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> you need to map and mount it manually.

I've never tried this before. Could you be more specific?

I understand how to use "mount." What I don't understand is how to
enter the system when my home is encrypted. I guess that I won't be
able to login. Is this correct?

Could you also tell me what I should have in fstab?

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 22.08.2012, Stayvoid wrote: 

> > you need to map and mount it manually.
> I've never tried this before. Could you be more specific?

First, you have to unlock your encrypted partition, e.g.

 cryptsetup luksOpen /dev/sdX home

> I understand how to use "mount." What I don't understand is how to
> enter the system when my home is encrypted. I guess that I won't be
> able to login. Is this correct?

You don't need the /home partition to boot your machine
properly. Unless your distribution has some tools which handle the
login/open/mount-procedure for you, you are not able to boot into
runlevel 5 directly. You could boot into rl1, open your encrypted
/home, mount it on /home

 mount /dev/mapper/home /home

and boot into rl5 afterwards (init 5).

> Could you also tell me what I should have in fstab?

That's impossible without more information on your partitions.
Unless you are targeting to do all the stuff yourself, I would
recommend using a dsitribution which handles the crypto-stuff for you,
e.g. Archlinux, Fedora, Opensuse, Debian, Ubuntu... whatever.

There's full support in at least Arch and Fedora.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 08/22/2012 08:40 AM, Stayvoid wrote:
>> you need to map and mount it manually.
> 
> I've never tried this before. Could you be more specific?
> 
> I understand how to use "mount." What I don't understand is how to
> enter the system when my home is encrypted. I guess that I won't be
> able to login. Is this correct?
> 
> Could you also tell me what I should have in fstab?

This needs to be done by your distribution's init system. For /home, your
distribution should support some flavor of /etc/crypttab.

You use crypttab to map an encrypted block device to an unencrypted block
device. This will show up as /dev/mapper/<name>. You then use fstab to specify
the mount as normal. So if your encrypted device is /dev/sda4, crypttab will
have a mapping of /dev/sda4 to <name>. Then, fstab will have a mount of
/dev/mapper/<name> to /home.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Javier Juan Martínez Cabezón]

On 22/08/12 17:40, Stayvoid wrote:
>> you need to map and mount it manually.
> 
> I've never tried this before. Could you be more specific?
> 
> I understand how to use "mount." What I don't understand is how to
> enter the system when my home is encrypted. I guess that I won't be
> able to login. Is this correct?
> 
> Could you also tell me what I should have in fstab?
> 
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

This is for gentoo and LUKS but you can adapt it to your scenary to suit
your needs:

http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Wed, Aug 22, 2012 at 07:40:34PM +0400, Stayvoid wrote:
> > you need to map and mount it manually.
> 
> I've never tried this before. Could you be more specific?

In this case, I strongly suggest you find out a lot more
about what you want to do before you do it. Otherwise
you may compromise security without intending to.

The man-page and FAQ for cryptsetup are a place to start. 
 
> I understand how to use "mount." What I don't understand is how to
> enter the system when my home is encrypted. I guess that I won't be
> able to login. Is this correct?

You could log in as "root"? You need to do mapping of
encrypted drives as root anyways...
 
> Could you also tell me what I should have in fstab?

Whatever fits your needs. I wouldn't know.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Christophe]

On Wed, Aug 22, 2012 at 04:10:01PM +0400, Stayvoid wrote:
> Hello,
> 
> I'd like to encrypt all partitions (or most of them) with plain dm-crypt.

What do you mean by plain dm-crypt ? If you mean aes-plain, then the mechanisms
present in most distributions won't be able to "see" your encrypted volumes, and
/etc/crypttab won't be of any use either.

However, as Arno sait you can do it with an initramfs image. Debian for instance
has a pretty convenient mechanism to automatically create initramfs images for
your different kernels, and you can use hooks to place your own scripts in it.
When you install cryptsetup, Debian updates all the initramfs images with the
cryptsetup binary. All you'll need to to after that is to add a custom boot
parameter to your bootloader (say encrypted_root=/dev/sdX), place a script in
the initramfs that will map the partition with cryptsetup (e.g. cryptsetup -c
aes-plain create root ${encrypted_root}) and update your /etc/fstab
(/dev/mapper/root / ...).

It requires a bit of fiddling but it'll work, and if your distro has such
mechanisms as Debian has, it won't break your configuration when updating grub
or the kernel because it'll run the hooks again.

Regards,
-- 
Christophe 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Thu, Aug 23, 2012 at 11:00:49AM +0200, Christophe wrote:
> On Wed, Aug 22, 2012 at 04:10:01PM +0400, Stayvoid wrote:
> > Hello,
> > 
> > I'd like to encrypt all partitions (or most of them) with plain dm-crypt.
> 
> What do you mean by plain dm-crypt ? 

plain dm-crypt = cryptsetup not for LUKS, i.e. a headerless
set-up. Used this way in the man-page and the FAQ. I assume 
that is what he meant. 

> If you mean aes-plain, then the mechanisms

That is something different. Plain dm-crypt defaults to
aes-cbc-essiv:sha256

> present in most distributions won't be able to "see" your encrypted volumes, and
> /etc/crypttab won't be of any use either.
> 
> However, as Arno sait you can do it with an initramfs image. Debian for
> instance has a pretty convenient mechanism to automatically create
> initramfs images for your different kernels, and you can use hooks to
> place your own scripts in it.  When you install cryptsetup, Debian updates
> all the initramfs images with the cryptsetup binary. 

Nice! Seems cryptsetup support in distros is definitely getting
better.

> All you'll need to
> to after that is to add a custom boot parameter to your bootloader (say
> encrypted_root=/dev/sdX), place a script in the initramfs that will map
> the partition with cryptsetup (e.g.  cryptsetup -c aes-plain create root
> ${encrypted_root}) and update your /etc/fstab (/dev/mapper/root / ...).

So no full support yet? Pity. As some others here have pointed out,
there are Distros with full cryptsetup integration. Gentoo seems
to be one. On the other hand, it seems some problems Ubuntu has
with LUKS are still not solved, so YMMV.

> It requires a bit of fiddling but it'll work, and if your distro has such
> mechanisms as Debian has, it won't break your configuration when updating
> grub or the kernel because it'll run the hooks again.

And on the plus side, if you ever run into a situation where
you need to access your encrypted partition with a rescue
system (seems to happen regularly), you know what to do from
doing parts yourself.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 23.08.2012, Arno Wagner wrote: 

> So no full support yet? Pity. As some others here have pointed out,
> there are Distros with full cryptsetup integration. Gentoo seems
> to be one.

Fedora has full support since F14, incl. support of keyfiles on
USB-media via initramfs/dracut.
  
> On the other hand, it seems some problems Ubuntu has
> with LUKS are still not solved, so YMMV.

Opensuse has had bad support (no encrypted root, problems with
bootscripts) two years ago, I don't know where they are now.
 
> And on the plus side, if you ever run into a situation where
> you need to access your encrypted partition with a rescue
> system (seems to happen regularly), you know what to do from
> doing parts yourself.

Sysresccd has good and updated cryptsetup and tools.

http://www.sysresccd.org

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Christophe]

On Thu, Aug 23, 2012 at 01:27:28PM +0200, Arno Wagner wrote:
> > What do you mean by plain dm-crypt ? 
> 
> plain dm-crypt = cryptsetup not for LUKS, i.e. a headerless
> set-up. Used this way in the man-page and the FAQ. I assume 
> that is what he meant. 

> > If you mean aes-plain, then the mechanisms
> 
> That is something different. Plain dm-crypt defaults to
> aes-cbc-essiv:sha256

Sorry, aes-plain was the default in previous versions if my memory is right...
anyway, without LUKS headers is what I had in mind, aes-plain being one of the
possible cipher strings.

> > present in most distributions won't be able to "see" your encrypted volumes, and
> > /etc/crypttab won't be of any use either.
> > 
> > However, as Arno sait you can do it with an initramfs image. Debian for
> > instance has a pretty convenient mechanism to automatically create
> > initramfs images for your different kernels, and you can use hooks to
> > place your own scripts in it.  When you install cryptsetup, Debian updates
> > all the initramfs images with the cryptsetup binary. 
> 
> Nice! Seems cryptsetup support in distros is definitely getting
> better.

Debian proposes an encrypted LVM partition scheme with cryptsetup/LUKS since a
few years now.
 
> > All you'll need to
> > to after that is to add a custom boot parameter to your bootloader (say
> > encrypted_root=/dev/sdX), place a script in the initramfs that will map
> > the partition with cryptsetup (e.g.  cryptsetup -c aes-plain create root
> > ${encrypted_root}) and update your /etc/fstab (/dev/mapper/root / ...).
> 
> So no full support yet? Pity. As some others here have pointed out,
> there are Distros with full cryptsetup integration. Gentoo seems
> to be one. On the other hand, it seems some problems Ubuntu has
> with LUKS are still not solved, so YMMV.

Debian has full support for cryptsetup/LUKS, but not for plain dm-crypt, not to
my knowledge anyway. I think this makes sense as there is no way to
automatically detect an encrypted partition with no header. 

The only advantage I can see in using encrypted partitions with no header is to
"hide" the encrypted volume, however the partition, cipher and hash function
have to be specified somewhere if one wants the distro to be able to do
automatic configuration. The bootloader will need it in its configuration, which
doesn't make it any better than LUKS in terms of discreetness.  

IMHO, successfully hiding an encrypted partition necessarily involves manual
operations, which makes plain dm-crypt out of the scope of a general distro such
as Debian.
 
-- 
Christophe 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Thu, Aug 23, 2012 at 05:10:25PM +0200, Christophe wrote:
> On Thu, Aug 23, 2012 at 01:27:28PM +0200, Arno Wagner wrote:
> > > What do you mean by plain dm-crypt ? 
> > 
> > plain dm-crypt = cryptsetup not for LUKS, i.e. a headerless
> > set-up. Used this way in the man-page and the FAQ. I assume 
> > that is what he meant. 
> 
> > > If you mean aes-plain, then the mechanisms
> > 
> > That is something different. Plain dm-crypt defaults to
> > aes-cbc-essiv:sha256
> 
> Sorry, aes-plain was the default in previous versions if my memory is right...
> anyway, without LUKS headers is what I had in mind, aes-plain being one of the
> possible cipher strings.

According to the FAQ Section 8.1 you are righ. (I wrote that,
so I think it is correct ;-)

Ok.

> > > present in most distributions won't be able to "see" your encrypted volumes, and
> > > /etc/crypttab won't be of any use either.
> > > 
> > > However, as Arno sait you can do it with an initramfs image. Debian for
> > > instance has a pretty convenient mechanism to automatically create
> > > initramfs images for your different kernels, and you can use hooks to
> > > place your own scripts in it.  When you install cryptsetup, Debian updates
> > > all the initramfs images with the cryptsetup binary. 
> > 
> > Nice! Seems cryptsetup support in distros is definitely getting
> > better.
> 
> Debian proposes an encrypted LVM partition scheme with cryptsetup/LUKS since a
> few years now.
>  
> > > All you'll need to
> > > to after that is to add a custom boot parameter to your bootloader (say
> > > encrypted_root=/dev/sdX), place a script in the initramfs that will map
> > > the partition with cryptsetup (e.g.  cryptsetup -c aes-plain create root
> > > ${encrypted_root}) and update your /etc/fstab (/dev/mapper/root / ...).
> > 
> > So no full support yet? Pity. As some others here have pointed out,
> > there are Distros with full cryptsetup integration. Gentoo seems
> > to be one. On the other hand, it seems some problems Ubuntu has
> > with LUKS are still not solved, so YMMV.
> 
> Debian has full support for cryptsetup/LUKS, 

For encrypted root? News to me, but would be a good thing.

> but not for plain dm-crypt, not to
> my knowledge anyway. I think this makes sense as there is no way to
> automatically detect an encrypted partition with no header. 
> 
> The only advantage I can see in using encrypted partitions with no header
> is to "hide" the encrypted volume, however the partition, cipher and hash

The second one is better resilience, as there is no header 
single-point-of-failure. Whether that is worth total loss of
key management depends on the application.

> function have to be specified somewhere if one wants the distro to be able
> to do automatic configuration.  

Thet is not the issue. Reasonable defaults would do that. The
issue is that the partiton type cannot be detected anymore 
without the key.

> The bootloader will need it in its
> configuration, which doesn't make it any better than LUKS in terms of
> discreetness.

Huh? What is the bootloader going to do with that info? Last
I checked, you still need a running kernel and system (possibly
in the form of an initrd) to do anything with encrypted partitions,
no matter whether LUKS or plain. I may be behind times here, if so,
please explain.

> IMHO, successfully hiding an encrypted partition necessarily involves
> manual operations, which makes plain dm-crypt out of the scope of a
> general distro such as Debian.

I agree. But hiding is not even supported by cryptsetup. 
Headerless operation is something else.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Milan Broz]

On 08/23/2012 06:07 PM, Arno Wagner wrote:
>> Debian has full support for cryptsetup/LUKS, 
> 
> For encrypted root? News to me, but would be a good thing.

I am using it for several years on Debian (supported only with combination
with lvm IIRC).

>> but not for plain dm-crypt, not to
>> my knowledge anyway. I think this makes sense as there is no way to
>> automatically detect an encrypted partition with no header. 
>>
>> The only advantage I can see in using encrypted partitions with no header
>> is to "hide" the encrypted volume, however the partition, cipher and hash
> 
> The second one is better resilience, as there is no header 
> single-point-of-failure. Whether that is worth total loss of
> key management depends on the application.

Well, you can have detached LUKS header on USB flash disk (optionally
with the whole boot partition) for example.

(cryptsetup has support for separate LUKS header but no support
in distros yet I think)

(You can even have different disk with another header with shifted data
offset in LUKS header and hide another volume inside the first
Not that it is comfortable though but possible...)

> 
>> function have to be specified somewhere if one wants the distro to be able
>> to do automatic configuration.  
> 
> Thet is not the issue. Reasonable defaults would do that. The
> issue is that the partiton type cannot be detected anymore 
> without the key.
> 
>> The bootloader will need it in its
>> configuration, which doesn't make it any better than LUKS in terms of
>> discreetness.
> 
> Huh? What is the bootloader going to do with that info? Last
> I checked, you still need a running kernel and system (possibly
> in the form of an initrd) to do anything with encrypted partitions,
> no matter whether LUKS or plain. I may be behind times here, if so,
> please explain.

Grub2 can handle LUKS directly.

(And separate header support is perhaps easy to add.)

Milan

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Thu, Aug 23, 2012 at 08:12:43PM +0200, Milan Broz wrote:
> On 08/23/2012 06:07 PM, Arno Wagner wrote:
> >> Debian has full support for cryptsetup/LUKS, 
> > 
> > For encrypted root? News to me, but would be a good thing.
> 
> I am using it for several years on Debian (supported only with combination
> with lvm IIRC).
> 
> >> but not for plain dm-crypt, not to
> >> my knowledge anyway. I think this makes sense as there is no way to
> >> automatically detect an encrypted partition with no header. 
> >>
> >> The only advantage I can see in using encrypted partitions with no header
> >> is to "hide" the encrypted volume, however the partition, cipher and hash
> > 
> > The second one is better resilience, as there is no header 
> > single-point-of-failure. Whether that is worth total loss of
> > key management depends on the application.
> 
> Well, you can have detached LUKS header on USB flash disk (optionally
> with the whole boot partition) for example.

That is not really a good idea. LUKS on Flash/SSD may not work 
as intended. I just added an entry for that to the FAQ (5.17). 
For some scenarios, plain dm-cryp is just the way to go.
Of course, it requires some understanding, e.g. a high-entropy
passphrase is a must.

> (cryptsetup has support for separate LUKS header but no support
> in distros yet I think)
> 
> (You can even have different disk with another header with shifted data
> offset in LUKS header and hide another volume inside the first
> Not that it is comfortable though but possible...)

Hehehe. Messy ;-)
 
> > 
> >> function have to be specified somewhere if one wants the distro to be able
> >> to do automatic configuration.  
> > 
> > Thet is not the issue. Reasonable defaults would do that. The
> > issue is that the partiton type cannot be detected anymore 
> > without the key.
> > 
> >> The bootloader will need it in its
> >> configuration, which doesn't make it any better than LUKS in terms of
> >> discreetness.
> > 
> > Huh? What is the bootloader going to do with that info? Last
> > I checked, you still need a running kernel and system (possibly
> > in the form of an initrd) to do anything with encrypted partitions,
> > no matter whether LUKS or plain. I may be behind times here, if so,
> > please explain.
> 
> Grub2 can handle LUKS directly.

Nice. Finally a reason to switch. 

> (And separate header support is perhaps easy to add.)

Should be. 

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Milan Broz]

On 08/23/2012 09:34 PM, Arno Wagner wrote:
>> Well, you can have detached LUKS header on USB flash disk (optionally
>> with the whole boot partition) for example.
> 
> That is not really a good idea. LUKS on Flash/SSD may not work 
> as intended. I just added an entry for that to the FAQ (5.17). 
> For some scenarios, plain dm-cryp is just the way to go.
> Of course, it requires some understanding, e.g. a high-entropy
> passphrase is a must.

(Where do you want to store that high-entropy passphrase?
I guess most of people will use... USB disk?)

Well, I think it is not that simple. You MUST HAVE high-entropy
passphrase in plain dmcrypt because encryption key is directly
computed (hash) from it.

Too easy for people to do this step wrong, which causes worse problems
than flash disk problems.
(Moreover, strandards like FIPS140 explicitly forbids any encryption key
derived directly from passphrases.)

LUKS uses kernel RNG to generate encryption key, always.

There is currently a lot of effort to ensure that /dev/urandom
cannot produce weak data even in extreme situations.

One problem is safe manipulation with keyslot on device, the second is separation
of metadata information (LUKS keyslots in this case) from data device.

(Dictionary attack is not possible for LUKS device if header is not available,
but it is possible for plain dm-crypt with weak passphrase.)

I have several notes to this disk/flash/SSD and will post it as separate mail...

But anyway, it all depends on threat model.

If it is only about securing data when laptop is stolen, no problem to
use SSD or flash disks. This should be mentioned IMHO because it is
most common use case.

Milan

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 24.08.2012, Milan Broz wrote: 

> There is currently a lot of effort to ensure that /dev/urandom
> cannot produce weak data even in extreme situations.

I'm more than happy that Intels hardware RNG isn't used as the only
source for randomness on systems where it is available (as proposed by 
Linus himself).

https://patchwork.kernel.org/patch/1161881/

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Fri, Aug 24, 2012 at 04:01:11PM +0200, Milan Broz wrote:
> On 08/23/2012 09:34 PM, Arno Wagner wrote:
> >> Well, you can have detached LUKS header on USB flash disk (optionally
> >> with the whole boot partition) for example.
> > 
> > That is not really a good idea. LUKS on Flash/SSD may not work 
> > as intended. I just added an entry for that to the FAQ (5.17). 
> > For some scenarios, plain dm-cryp is just the way to go.
> > Of course, it requires some understanding, e.g. a high-entropy
> > passphrase is a must.
> 
> (Where do you want to store that high-entropy passphrase?
> I guess most of people will use... USB disk?)

My head? 
 
> Well, I think it is not that simple. You MUST HAVE high-entropy
> passphrase in plain dmcrypt because encryption key is directly
> computed (hash) from it.

Indeed. 

> Too easy for people to do this step wrong, which causes worse problems
> than flash disk problems.

That is why plain dm-crypt is not for beginners. Most people
will be best served by using LUKS. But unless it is a massive
development or maintanance problem, having plain dm-crypt as 
an option should not be an issue. Or do you see any larger
problems supporting both?

Plain dm-crypt is useful in special situations, for example
for decrypt_derived or when you have very little space. There
are others as well.

> (Moreover, strandards like FIPS140 explicitly forbids any encryption key
> derived directly from passphrases.)

Well, for non-experts that is reasonable. Some people still
may want to derive keys from  high-entropy passphrases.
FIPS140 is important, but it is not everything.
 
> LUKS uses kernel RNG to generate encryption key, always.
> 
> There is currently a lot of effort to ensure that /dev/urandom
> cannot produce weak data even in extreme situations.

Good.
 
> One problem is safe manipulation with keyslot on device, the second is
> separation of metadata information (LUKS keyslots in this case) from data
> device.
> 
> (Dictionary attack is not possible for LUKS device if header is not
> available, but it is possible for plain dm-crypt with weak passphrase.)

As amply warned about in the decumentation. LUKS and plain dm-crypt
have different philosophies: LUKS tries to protect the user at
all cost, while plain dm-crypt gives as much control to the user
as possible. That measn most users should go the LUKS way. 

> I have several notes to this disk/flash/SSD and will post it as separate
> mail...
> 
> But anyway, it all depends on threat model.
> 
> If it is only about securing data when laptop is stolen, no problem to
> use SSD or flash disks. This should be mentioned IMHO because it is
> most common use case.

I agree. What you lose is secure key-management (old keys may 
still work) and reliable wipe by header overwrite. Both do
not matter in the generic stolen-laptop scenario. The first 
may matter if the theft is a targetted attack. The second may
matter if you want to implement active tamper-proofing. 

I will add the "generic stolen Laptop" to the FAQ.
 
Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Fri, Aug 24, 2012 at 04:40:28PM +0200, Heinz Diehl wrote:
> On 24.08.2012, Milan Broz wrote: 
> 
> > There is currently a lot of effort to ensure that /dev/urandom
> > cannot produce weak data even in extreme situations.
> 
> I'm more than happy that Intels hardware RNG isn't used as the only
> source for randomness on systems where it is available (as proposed by 
> Linus himself).
> 
> https://patchwork.kernel.org/patch/1161881/

I agree. I think Linux does not quite understand the issue here.
If some Intel chips are compromised, nothing but a very expensive
hardware analysis or a massive intelligence blunder would reveal
that, hence it is very, very unlikely for Intel (or any other
CPU maker) to get caught red-handed.

On the other hand, mixing in a reasonable amount of other 
randomness negates any attack possibilities via the HW RNG
and at the same time allows it to be used as high-quality
"stretching" material. For example, using 512 bits of
other entropy and stretch this to a few MB with the HW RNG 
would still be fine (if done right) even if the HW RNG is 
compromised.

The solurtion by Tso makes perfect sense cryptographically
and from a risk-management perspective. Never put all your
eggs in one basket unless there really is no other choice.

Arno

-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

Hello there,

Let's move back to the initial questions...

I'd like to use a plain version of dm-crypt because it doesn't
store a header on a disk. (Yes, I know that LUKS is a recommended
way, but I've already made my choice.)

I haven't found any guides to the plain version that's why I
decided to ask first.

Here is what I'm going to do:
(These notes are based on this guide [1].
I'm using a LiveUSB.)

1. Overwrite a hard disk:

# dd if=/dev/urandom of=/dev/sda bs=1M


2. Create partitions:

# fdisk /dev/sda

Here is my partition scheme:

Device    Boot    Start         End     Blocks  Id  System
/dev/sda1          2048      206847     102400  83  Linux
/dev/sda2        206848     2303999    1048576  82  Linux
/dev/sda3       2304000   312581807  155138904  83  Linux

* /dev/sda1 -- /boot;
* /dev/sda2 -- swap;
* /dev/sda3 -- the rest.

When can I create the filesystems?
Can I do it at this step?

3. Mapping partitions:

# cryptsetup -y -c aes-xts-plain -s 512 create swap /dev/sda2
# cryptsetup -y -c aes-xts-plain -s 512 create main /dev/sda3

After this step the guide [1] suggests to unlock LUKS partitions:

# cryptsetup luksOpen /dev/<partitions name> <device-mapper name>

How to do it using the plain version of dm-crypt?
Is it even necessary?


4. Encrypting the swap partition with suspend-to-disk support:

How to do it using the plain version?


What else should be done to finish the configuration?

[1] https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

Hi,

On Wed, Sep 05, 2012 at 08:21:36AM +0400, Stayvoid wrote:
> Hello there,
> 
> Let's move back to the initial questions...
> 
> I'd like to use a plain version of dm-crypt because it doesn't
> store a header on a disk. (Yes, I know that LUKS is a recommended
> way, but I've already made my choice.)

That is fine. I am doing the same in some places.

> I haven't found any guides to the plain version that's why I
> decided to ask first.

That is because the plain version is actually simpler to use,
it just is missing most "enterprise" features.
 
> Here is what I'm going to do:
> (These notes are based on this guide [1].
> I'm using a LiveUSB.)
> 
> 1. Overwrite a hard disk:
> 
> # dd if=/dev/urandom of=/dev/sda bs=1M

That will be very slow. The way fastest method is to mapl
with plain dm-crypt and a random key (like the typical swap
set-up) and then overwrite with zeros.

You solution will work though, although if you do it with

  dd_rescue /dev/urandom /dev/sda

you get a progess indicator.

> 
> 2. Create partitions:
> 
> # fdisk /dev/sda
> 
> Here is my partition scheme:
> 
> Device    Boot    Start         End     Blocks  Id  System
> /dev/sda1          2048      206847     102400  83  Linux
> /dev/sda2        206848     2303999    1048576  82  Linux
> /dev/sda3       2304000   312581807  155138904  83  Linux 
>
> * /dev/sda1 -- /boot;
> * /dev/sda2 -- swap;
> * /dev/sda3 -- the rest.

Looks reasonable.
 
> When can I create the filesystems?
> Can I do it at this step?

No. Nothing is encrypted.You could create the boot
filesystem if that stays unencrypted.

> 3. Mapping partitions:
> 
> # cryptsetup -y -c aes-xts-plain -s 512 create swap /dev/sda2
> # cryptsetup -y -c aes-xts-plain -s 512 create main /dev/sda3
> 
> After this step the guide [1] suggests to unlock LUKS partitions:
> 
> # cryptsetup luksOpen /dev/<partitions name> <device-mapper name>
> 
> How to do it using the plain version of dm-crypt?
> Is it even necessary?

No. You just map it like you stated and then create the filesystem
on the mapped device. The luksFormat step does not happen.

So: 

mke2fs -j /dev/mapper/main
mkswap /dev/mapper/main

> 
> 4. Encrypting the swap partition with suspend-to-disk support:
> 
> How to do it using the plain version?

No idea. Suspend-to-disk is insecure unless done right and it
needs to be done right by your distro. Basically you
can put in "cryptsetup create" for any "cryptsetup luksOpen" and
swap the arguments.
"cryptsetup close" and "cryptsetup luskClose" are synonyms
AFAIK, i.e. both remove the mapping whether plain or LUKS.

Arno



 
> 
> What else should be done to finish the configuration?
> 
> [1] https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS
> 
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> You solution will work though, although if you do it with

>  dd_rescue /dev/urandom /dev/sda

> you get a progess indicator.

In that case it's also possible to check the progress like this:

$ kill -USR1 $(pidof dd)

(This should be typed in another terminal.)


> No. You just map it like you stated and then create the filesystem
> on the mapped device.

How to map it? Will the following work?

$ cryptsetup create /dev/sda2 boot
$ cryptsetup create /dev/sda3 main


> mkswap /dev/mapper/main

Is this a typo? I guess that it should be changed to:

mkswap /dev/mapper/swap


> No idea. Suspend-to-disk is insecure unless done right and it
> needs to be done right by your distro.

What about this option [1]?
Is it secure?

I know that some people don't use swap at all because of security issues.
But I'd like to use it.

By the way, are there any differences between a swap partition and a
swap file (in terms of security)?

[1] https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Without_suspend-to-disk_support

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Thu, Sep 06, 2012 at 04:54:18PM +0400, Stayvoid wrote:
> > You solution will work though, although if you do it with
> 
> >? dd_rescue /dev/urandom /dev/sda
> 
> > you get a progess indicator.
> 
> In that case it's also possible to check the progress like this:
> 
> $ kill -USR1 $(pidof dd)
> 
> (This should be typed in another terminal.)
> 
> 
> > No. You just map it like you stated and then create the filesystem
> > on the mapped device.
> 
> How to map it? Will the following work?
> 
> $ cryptsetup create /dev/sda2 boot
> $ cryptsetup create /dev/sda3 main

Yes, "create" is the mapping command for plain dm-crypt.
 
> 
> > mkswap /dev/mapper/main
> 
> Is this a typo? I guess that it should be changed to:
> 
> mkswap /dev/mapper/swap

Yes.

> 
> > No idea. Suspend-to-disk is insecure unless done right and it
> > needs to be done right by your distro.
> 
> What about this option [1]?
> Is it secure?

Well, it does not have the security problems of suspend-to-disk
at least ;-)
Whether it is ecyure depends on some factors. For example, you
need a high-entropy passphrase for plain dm-crypt to be secure.
See FAQ for more info.
 
> I know that some people don't use swap at all because of security issues.
> But I'd like to use it.

Encrypted swap is generally fine, as long as it gets a random
encryption key on system boot. I have been doing that for a 
while now, no problems.

> By the way, are there any differences between a swap partition and a
> swap file (in terms of security)?

Depends. For example, if you use a journaling filesystem or a filesystem
where writes may not overwrite old data, stuff can survive far longer
than expected. The same can happen with SWAP on SSD, even if ut
goes to its own partition.

Usually, the secure option is to use swap on a magnetic disk 
that is encrypted with a random key chosen at system boot. If
you are paranoid, change the key periodically (cron-job).

Arno 

> [1] https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Without_suspend-to-disk_support
> 
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 06.09.2012, Arno Wagner wrote: 

> Encrypted swap is generally fine, as long as it gets a random
> encryption key on system boot.

This statement implies that swap is insecure if it doesn't get a
random encrption key on system boot. Why do you think it is?

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Thu, Sep 06, 2012 at 07:53:09PM +0200, Heinz Diehl wrote:
> On 06.09.2012, Arno Wagner wrote: 
> 
> > Encrypted swap is generally fine, as long as it gets a random
> > encryption key on system boot.
> 
> This statement implies that swap is insecure if it doesn't get a
> random encrption key on system boot. Why do you think it is?

I was thinking about automatic swap set-up. If you do that
with a non-random key, you have to store it somewhere and that 
will be a problem. This assumes that encrypted swap is
completely independent from the presence (or absence) of any 
other encryption.

Or are you asking why unencrypted swap is insecure?

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

Hi,

I got the following error when I typed this command:
cryptsetup -y -c aes-xts-plain -s 512 create swap /dev/sda2
Cannot use device /dev/sda2 which is in use (already mapped or mounted).

There is nothing similar in either fstab or mount's output.
There is nothing in /dev/mapper except control.

What else should be checked?

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

From the top of my head, have you checked whether it is in 
use as swap? "swapon -s" should do that.

Arno



On Fri, Sep 07, 2012 at 08:10:19PM +0400, Stayvoid wrote:
> Hi,
> 
> I got the following error when I typed this command:
> cryptsetup -y -c aes-xts-plain -s 512 create swap /dev/sda2
> Cannot use device /dev/sda2 which is in use (already mapped or mounted).
> 
> There is nothing similar in either fstab or mount's output.
> There is nothing in /dev/mapper except control.
> 
> What else should be checked?
> 
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> From the top of my head, have you checked whether it is in
> use as swap? "swapon -s" should do that.

Yep, it's in use.

How bad is it? (I haven't mapped the partitions yet.)
I remember that I ran "partprobe -s" after the partitioning.

What should I do to fix this?
Should I run "dd_rescue /dev/urandom /dev/sda" again?

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Milan Broz]

On 09/08/2012 04:50 AM, Stayvoid wrote:
>> From the top of my head, have you checked whether it is in
>> use as swap? "swapon -s" should do that.
> 
> Yep, it's in use.
> 
> How bad is it? (I haven't mapped the partitions yet.)
> I remember that I ran "partprobe -s" after the partitioning.

Are you sure partitions are not already mapped?
(e.g. parted does this automatically)

try lsblk - if there are DM device mapping partitions,
remove them using kpartx -d

for swap just run swapoff

Milan

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 06.09.2012, Arno Wagner wrote: 

> I was thinking about automatic swap set-up. If you do that
> with a non-random key, you have to store it somewhere and that 
> will be a problem.

I created my swap partiton while installing the distribution. The
whole harddisk (laptop) is LUKS/dmcrypt encrypted. When I start up the
machine, all I have to do is to provide the proper passphrase, and all
my encrypted partitions will be unlocked, incl. swap.

As far as I can see, dracut stores the passphrase in memory, unlocks
the root-partition first, and runs the same passphrase on all the
other LUKS-devices afterwards. I can't see how this procedure could be
a problem related to swap, and why I maybe should choose a random key
over a predefined one.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Sat, Sep 08, 2012 at 10:13:38AM +0200, Heinz Diehl wrote:
> On 06.09.2012, Arno Wagner wrote: 
> 
> > I was thinking about automatic swap set-up. If you do that
> > with a non-random key, you have to store it somewhere and that 
> > will be a problem.
> 
> I created my swap partiton while installing the distribution. The
> whole harddisk (laptop) is LUKS/dmcrypt encrypted. When I start up the
> machine, all I have to do is to provide the proper passphrase, and all
> my encrypted partitions will be unlocked, incl. swap.
> 
> As far as I can see, dracut stores the passphrase in memory, unlocks
> the root-partition first, and runs the same passphrase on all the
> other LUKS-devices afterwards. I can't see how this procedure could be
> a problem related to swap, and why I maybe should choose a random key
> over a predefined one.

Swap can be encrypted with a one-time passphrase. This is more
secure as a constan passphrase. It can also be done 
non-interactively. The (slight) security decrease when encrypting
swap with a static passphrase is that in the future you may still
find stuff in there if the passphrase gets compromised.

The point is that there is no reason to include swap in 
a normal encryption scheme and doing it with a random passphrase
even increases security. In addition, encrypted swap can
be something you want on a system that does not encrypt anything
else.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 08.09.2012, Arno Wagner wrote: 

> Swap can be encrypted with a one-time passphrase. This is more
> secure as a constant passphrase. It can also be done 
> non-interactively. The (slight) security decrease when encrypting
> swap with a static passphrase is that in the future you may still
> find stuff in there if the passphrase gets compromised.

When the passphrase gets compromised it'll be of no relevance what
somebody will find inside the unencrypted swap. All swap content 
is derived from data of the system itself, which then also will be
compromised. At least if a global passphrase is used.

If every partition on a system has its own and unique passphrase, nobody
would attack swapspace in the first place. There's more to get
attacking the users /home or the root-partition.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Marc MERLIN]

On Sat, Sep 08, 2012 at 03:26:54PM +0200, Arno Wagner wrote:
> The point is that there is no reason to include swap in 
> a normal encryption scheme and doing it with a random passphrase

Unless you use suspend to disk of course :)

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Sat, Sep 08, 2012 at 04:37:18PM +0200, Heinz Diehl wrote:
> On 08.09.2012, Arno Wagner wrote: 
> 
> > Swap can be encrypted with a one-time passphrase. This is more
> > secure as a constant passphrase. It can also be done 
> > non-interactively. The (slight) security decrease when encrypting
> > swap with a static passphrase is that in the future you may still
> > find stuff in there if the passphrase gets compromised.
> 
> When the passphrase gets compromised it'll be of no relevance what
> somebody will find inside the unencrypted swap. All swap content 
> is derived from data of the system itself, which then also will be
> compromised. At least if a global passphrase is used.
> 
> If every partition on a system has its own and unique passphrase, nobody
> would attack swapspace in the first place. There's more to get
> attacking the users /home or the root-partition.

So? You miss the point: If swap can be securely encrypted
independently, this decreases overall system complexity and
hence increase security. For example, swap encryption done
this way will not be subject to any problems with weak 
passwords.

And yes, it is possible that there are things in swap that
cannot be found in the data partitions. Swap encryption 
solves a different problem than data partition encryption.

That other encryption could be insecure on the system is
immaterial, swap can (and should) be solved on its own.
And, as I have pointed out, there are reasons to want swap
encryption even when noting else on the system is encrypted,
so the independent approach needs to be engineered anyways.


Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Heinz Diehl]

On 08.09.2012, Arno Wagner wrote: 

> So? You miss the point: If swap can be securely encrypted
> independently, this decreases overall system complexity and
> hence increase security.

If swap is created on installation, encrypted with the same 
passphrase as the rest of the system, and just gets opened while
booting, it is clearly _less_ complex than having it created on every 
single (re)boot, incl. generating a new passphrase. 
You simply boot, enter the passphrase and you're done.

> For example, swap encryption done
> this way will not be subject to any problems with weak 
> passwords.

If you use weak passphrases, you have a substantial problem which goes
far beyond the fact of automatic swapspace generation/encryption on
boot vs. singe passphrase setup. Your whole system would be prone to
brute force / dictionary attacks. Assuming your swap passphrase is
randomly generated at boot-time, your swapspace would be secure, while
the rest is not. That makes no sense to me.
 
> And yes, it is possible that there are things in swap that
> cannot be found in the data partitions. Swap encryption 
> solves a different problem than data partition encryption.

You're right, I don't get the point. Really.
 
> That other encryption could be insecure on the system is
> immaterial, swap can (and should) be solved on its own.

Frankly, nobody would try to attack swap on a fully encrypted system
in the first place. If an attacker thinks it's worth the effort, where
would he/she think are most of the relevant data? I strongly guess it
would be the root and/or the home partition.

> And, as I have pointed out, there are reasons to want swap
> encryption even when noting else on the system is encrypted,
> so the independent approach needs to be engineered anyways.

I agree in this situation, just I don't understand why one would do
that when all the rest is unencrypted. It's more likely that the
various /tmp direcories will contain leaked sensitive data, or that 
sensitive data is dumped to disk under a crash or system fault. Even
the randomly generated passphrase could leak/be dumped, because the
root partition will be mounted before the swap is generated.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Sat, Sep 08, 2012 at 06:39:07PM +0200, Heinz Diehl wrote:
> On 08.09.2012, Arno Wagner wrote: 
> 
> > So? You miss the point: If swap can be securely encrypted
> > independently, this decreases overall system complexity and
> > hence increase security.
> 
> If swap is created on installation, encrypted with the same 
> passphrase as the rest of the system, and just gets opened while
> booting, it is clearly _less_ complex than having it created on every 
> single (re)boot, incl. generating a new passphrase. 
> You simply boot, enter the passphrase and you're done.

It is not. The complexity is lesser because a single system 
doing two different things is basically always more complex 
than two systems doint the things individually. It may not
appear to be from the code, but design, architecture and 
security analysis are part of the system and they definitely 
get more complex. This poses for example an incresed risk to 
get it wrong., also on any changes.

The user-interface may be more complex though. Decreased risk
of user errors and decreased user inconvenience are the only 
possible advantages of having one thing do two very different
tasks. It is not in this case as one task (swap encryption) 
does not require user interaction but is completely autonomous.

One important paradigm in secure system design is to automatize
anythign that can be automatized without decreasing security.
For swap, automatizing encryption increases security.

What you seem to miss is that swap encryption and data encryption 
are two very different things. One protects data potentially
leaked from memory and one protects data at rest. Memory
needs more protection, as there can be a lot of sensitive
data in there that never makes it to disk. 

True, it sometimes requires design errors or system 
shortcommings. Some examples: 

- Neither Firefox nor Opera lock any memory when an SSL 
  connection is active. (Suspected this a long time, but just 
  checked. It is in the  VmLck field in /proc/<pid>/status.)
  This means SSL session keys will not be protected against 
  swapping and the same for anything sent or received over SSL.

- Upgrade the last item. Say you use Tor for something secret. 
  Same risk.

- The same is likely true for any chat application.  
 
> > For example, swap encryption done
> > this way will not be subject to any problems with weak 
> > passwords.
> 
> If you use weak passphrases, you have a substantial problem which goes
> far beyond the fact of automatic swapspace generation/encryption on
> boot vs. singe passphrase setup. 

But if you only encrypt wap, this problem will not be present
with a random key at all.

> Your whole system would be prone to
> brute force / dictionary attacks. Assuming your swap passphrase is
> randomly generated at boot-time, your swapspace would be secure, while
> the rest is not. That makes no sense to me.

Swap needs more protection than data at rest. The reason is that
the risk to swap is data-leakage from main memory. There can be 
things in swap that never make it to data storage.

> > And yes, it is possible that there are things in swap that
> > cannot be found in the data partitions. Swap encryption 
> > solves a different problem than data partition encryption.
> 
> You're right, I don't get the point. Really.
>  
> > That other encryption could be insecure on the system is
> > immaterial, swap can (and should) be solved on its own.
> 
> Frankly, nobody would try to attack swap on a fully encrypted system
> in the first place. If an attacker thinks it's worth the effort, where
> would he/she think are most of the relevant data? I strongly guess it
> would be the root and/or the home partition.

Oh, yes, a competent attacker would very much like to look
at swap as well, in particular if it is free anyways (only one
passphrase for everything). In autonomous swap encryption, the 
attacker has to spent likely more effort to get at swap. Which 
is appropriate as it may need more protection anyways, depending 
on attacker model.

> > And, as I have pointed out, there are reasons to want swap
> > encryption even when noting else on the system is encrypted,
> > so the independent approach needs to be engineered anyways.
> 
> I agree in this situation, just I don't understand why one would do
> that when all the rest is unencrypted. It's more likely that the
> various /tmp direcories will contain leaked sensitive data, or that 
> sensitive data is dumped to disk under a crash or system fault. 

That is rather unlikely. It also only happens on crashes, so 
the user will know. And it requires misconfiguration. And it 
is subject to the permission system. Nothing of that is true 
for swap.

> Even
> the randomly generated passphrase could leak/be dumped, because the
> root partition will be mounted before the swap is generated.

It could basically only leak to swap. And that is not a problem 
with a random key. It may be with a non-random one.

Now, all this is not a make-or-break item in most scenarios.
Dping swap encryption with a static key is not massively less
secure than doing it with a random key in most scenarios.

But if you want to do it right, then swap gets encrypted 
automatically with a one-time random key (that may even get 
regenerated periodically) and data gets encrypted with a user 
supplied key or a key that is protected by a user-supplied 
passphrase.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> try lsblk - if there are DM device mapping partitions,
> remove them using kpartx -d

What's "DM"?

lsblk shows /dev/sda.

There is no kpartx in the repo. What should I use instead?

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

Arno,

I'm not sure that I got the idea.
How to access encrypted partitions after booting?
And how to unmount / encrypt / temporary disable them?
(I hope that my terminology is clear.)
In other words, what's the usage pattern?

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/14/2012 06:52 PM, Stayvoid wrote:
> Arno,
> 
> I'm not sure that I got the idea. How to access encrypted partitions after
> booting? And how to unmount / encrypt / temporary disable them? (I hope that
> my terminology is clear.) In other words, what's the usage pattern?
> 

Assuming you've run luksFormat on some block device (/dev/sda2), and you're
booted into your initrd.

# cryptsetup luksOpen /dev/sda2 root

will create a new block device at /dev/mapper/root.

So you've used the kernel device mapper to map one block device into another
block device. You then proceed with /dev/mapper/root as if it's another other
block device.

So you (or your distro rather) needs to do something like

# mount /dev/mapper/root /mnt
# switch_root /mnt /sbin/init

The distribution you use will affect exactly how you configure this because it's
not standard. (It'd be great if cryptsetup at least provided some sort of
reference parser for /etc/crypttab, but they feel it's out of scope, so this
standardization is being done by systemd. That said, root [and /usr] is going to
be a little different than everything else)

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/14/2012 07:09 PM, Matthew Monaco wrote:
> On 09/14/2012 06:52 PM, Stayvoid wrote:
>> Arno,
>>
>> I'm not sure that I got the idea. How to access encrypted partitions after
>> booting? And how to unmount / encrypt / temporary disable them? (I hope that
>> my terminology is clear.) In other words, what's the usage pattern?
>>
> 
> Assuming you've run luksFormat on some block device (/dev/sda2), and you're
> booted into your initrd.
> 
> # cryptsetup luksOpen /dev/sda2 root
> 
> will create a new block device at /dev/mapper/root.
> 
> So you've used the kernel device mapper to map one block device into another
> block device. You then proceed with /dev/mapper/root as if it's another other
> block device.
> 

Sorry, I meant "any other" block device.

> So you (or your distro rather) needs to do something like
> 
> # mount /dev/mapper/root /mnt
> # switch_root /mnt /sbin/init
> 
> The distribution you use will affect exactly how you configure this because it's
> not standard. (It'd be great if cryptsetup at least provided some sort of
> reference parser for /etc/crypttab, but they feel it's out of scope, so this
> standardization is being done by systemd. That said, root [and /usr] is going to
> be a little different than everything else)
> 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Javier Juan Martínez Cabezón]

On 15/09/12 02:52, Stayvoid wrote:
> Arno,
> 
> I'm not sure that I got the idea.
> How to access encrypted partitions after booting?
> And how to unmount / encrypt / temporary disable them?
> (I hope that my terminology is clear.)
> In other words, what's the usage pattern?
> 
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

"man cryptsetup" answers your questions

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Two Spirit]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

I'm interested in knowing what are some of the trade offs of using the LUKS
header v not using the LUKS header.Since I assume the content of the
encrypted data is secure, it doesn't matter if someone knows the data is
encrypted and has a header and the header only helps in recovery, so I'm
not quite seeing what would be an advantage of not using LUKS, but from the
email below, there seems to be some reason.

On Wed, Sep 5, 2012 at 6:01 AM, Arno Wagner <arno@wagner.name> wrote:

> Hi,
>
> On Wed, Sep 05, 2012 at 08:21:36AM +0400, Stayvoid wrote:
> > Hello there,
> >
> > Let's move back to the initial questions...
> >
> > I'd like to use a plain version of dm-crypt because it doesn't
> > store a header on a disk. (Yes, I know that LUKS is a recommended
> > way, but I've already made my choice.)
>
> That is fine. I am doing the same in some places.
>
>

[-- Attachment #2: Type: text/html, Size: 1243 bytes --]

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Javier Juan Martínez Cabezón]

On 19/09/12 06:15, Two Spirit wrote:
> I'm interested in knowing what are some of the trade offs of using the LUKS
> header v not using the LUKS header.Since I assume the content of the
> encrypted data is secure, it doesn't matter if someone knows the data is
> encrypted and has a header and the header only helps in recovery, so I'm
> not quite seeing what would be an advantage of not using LUKS, but from the
> email below, there seems to be some reason.
> 
> On Wed, Sep 5, 2012 at 6:01 AM, Arno Wagner <arno@wagner.name> wrote:
> 
>> Hi,
>>
>> On Wed, Sep 05, 2012 at 08:21:36AM +0400, Stayvoid wrote:
>>> Hello there,
>>>
>>> Let's move back to the initial questions...
>>>
>>> I'd like to use a plain version of dm-crypt because it doesn't
>>> store a header on a disk. (Yes, I know that LUKS is a recommended
>>> way, but I've already made my choice.)
>>
>> That is fine. I am doing the same in some places.
>>
>>
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Please check tha FAQ's

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Wed, Sep 19, 2012 at 06:52:19AM +0200, Javier Juan Mart?nez Cabez?n wrote:
> On 19/09/12 06:15, Two Spirit wrote:
> > I'm interested in knowing what are some of the trade offs of using the LUKS
> > header v not using the LUKS header.Since I assume the content of the
> > encrypted data is secure, it doesn't matter if someone knows the data is
> > encrypted and has a header and the header only helps in recovery, so I'm
> > not quite seeing what would be an advantage of not using LUKS, but from the
> > email below, there seems to be some reason.
> > 
> Please check tha FAQ's

Indeed. Basically you get passphrase management
(up to 8, can be changed) and protection for
passphrases that are not so high in entropy 
(iteration, salting). You also get management for
non-default crypto parameters.

Main drawback is that if you damage the header,
everything is gine. That is also an advantage if you
want easy secure deletion though.

Details in the FAQ, mostly Sections 2, 5 and 6. 

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> So you (or your distro rather) needs to do something like
>
> # mount /dev/mapper/root /mnt
> # switch_root /mnt /sbin/init
>
> The distribution you use will affect exactly how you configure this because
> it's not standard.

It's "something completely different."
I'm using Lemote YeeLoong and PMON as a bootloader.

PMON's conf is pretty easy to understand:

title 1
kernel (wd0,0)/vmlinuz-linux-libre
initrd (wd0,0)/initramfs-linux-libre.img
args root=/dev/mapper/main console=tty no_auto_cmd

But this is not working.
It drops me to a recovery shell:

:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
ERROR: device '/dev/mapper/main' not found. Skipping fsck.
ERROR: Unable to find root device '/dev/mapper/main'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
Trying to continue (this will most likely fail) ...
:: mounting '/dev/mapper/main' on real root
mount: special device /dev/mapper/main does not exist
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off

Should it work this way?
Should I decrypt the main partition using the recovery shell?
(I can't access /dev/mapper from the recovery shell.)

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Javier Juan Martínez Cabezón]

One question, is your devfs mounted or are you using static nodes
under /dev (as created with mknod)?

2012/9/20, Stayvoid <stayvoid@gmail.com>:
>> So you (or your distro rather) needs to do something like
>>
>> # mount /dev/mapper/root /mnt
>> # switch_root /mnt /sbin/init
>>
>> The distribution you use will affect exactly how you configure this
>> because
>> it's not standard.
>
> It's "something completely different."
> I'm using Lemote YeeLoong and PMON as a bootloader.
>
> PMON's conf is pretty easy to understand:
>
> title 1
> kernel (wd0,0)/vmlinuz-linux-libre
> initrd (wd0,0)/initramfs-linux-libre.img
> args root=/dev/mapper/main console=tty no_auto_cmd
>
> But this is not working.
> It drops me to a recovery shell:
>
> :: running early hook [udev]
> :: running hook [udev]
> :: Triggering uevents...
> ERROR: device '/dev/mapper/main' not found. Skipping fsck.
> ERROR: Unable to find root device '/dev/mapper/main'.
> You are being dropped to a recovery shell
>     Type 'exit' to try and continue booting
> sh: can't access tty; job control turned off
> Trying to continue (this will most likely fail) ...
> :: mounting '/dev/mapper/main' on real root
> mount: special device /dev/mapper/main does not exist
> You are now being dropped into an emergency shell.
> sh: can't access tty; job control turned off
>
> Should it work this way?
> Should I decrypt the main partition using the recovery shell?
> (I can't access /dev/mapper from the recovery shell.)
>
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> One question, is your devfs mounted or are you using static nodes
> under /dev (as created with mknod)?

I don't know.
How to check?

Regarding devfs... I thought that latest versions of the Linux kernel use udev.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner]

On Fri, Sep 21, 2012 at 09:01:52AM +0400, Stayvoid wrote:
> > One question, is your devfs mounted or are you using static nodes
> > under /dev (as created with mknod)?
> 
> I don't know.
> How to check?

With devfs the output of "df" should have something like
      udev                   10M  296K  9.8M   3% /dev
and there shoud be a directory .udev/ in /dev.
 
> Regarding devfs... I thought that latest versions of 
> the Linux kernel use udev.

As with many other features, you can use udev or the old
mechanism at your choice. I think you need to recompile 
though.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> With devfs the output of "df" should have something like
>       udev                   10M  296K  9.8M   3% /dev
> and there shoud be a directory .udev/ in /dev.

Should I check this in a recovery shell?

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> With devfs the output of "df" should have something like
>      udev                   10M  296K  9.8M   3% /dev
> and there shoud be a directory .udev/ in /dev.

Recovery shell:
# df
Filesystem
dev        ...
run        ...

USB stick with the same kernel:
# df
Filesystem
rootfs     ...
dev        ...
run        ...
/dev/sdc1  ...
shm        ...
tmpfs      ...

/dev/udev doesn't exist in both cases.

I'm still trying to understand how to mount and decrypt my
partitions. I've been told that a man page should help me, but I
can't see anything helpful there.

I'm using a plain version, and
there are four options: create, remove, status, resize.
Which one should I use to "recreate" my old mapping?
Is it possible? Am I'm missing something?

I can't see my mappings in /dev/mapper because I'm running from
a USB stick.

I can't mount the partitions, mount shows a standard "wrong fs
type" error.

Could you tell me what should I do to access the data on the
partition?

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

Hi,

Let's forget about Lemote specific issues.

For some reason I can't mount my partition when I'm using a USB stick.

Here is what I did:

1. Booted from a USB stick;

2. Created a mapping:

   # cryptsetup -c aes-xts-plain -s 512 -y create main /dev/sda3

3. Created a filesystem:

   # mkfs.ext3 /dev/mapper/main

4. Mounted it:

   # mount -t ext3 /dev/mapper/main /media/parabola

   It worked fine.

5. Unmounted it:

   # umount /media/parabola

6. Detached the partition:

   # cryptsetup remove main

Then I tried to use the same partition:

# cryptsetup create main /dev/sda3
# mount -t ext3 /dev/mapper/main /media/parabola

mount failed.

"If the password is not correct, the mount command will fail. In this
case simply remove the map sdc1 (cryptsetup remove sdc1) and create it
again." [1]

I'm sure that I was using the right password.

What is the problem?

[1] http://sleepyhead.de/howto/?href=cryptpart

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/24/2012 09:12 PM, Stayvoid wrote:
> Hi,
> 
> Let's forget about Lemote specific issues.
> 
> For some reason I can't mount my partition when I'm using a USB stick.
> 
> Here is what I did:
> 
> 1. Booted from a USB stick;
> 
> 2. Created a mapping:
> 
>    # cryptsetup -c aes-xts-plain -s 512 -y create main /dev/sda3
> 
> 3. Created a filesystem:
> 
>    # mkfs.ext3 /dev/mapper/main
> 
> 4. Mounted it:
> 
>    # mount -t ext3 /dev/mapper/main /media/parabola
> 
>    It worked fine.
> 
> 5. Unmounted it:
> 
>    # umount /media/parabola
> 
> 6. Detached the partition:
> 
>    # cryptsetup remove main
> 
> Then I tried to use the same partition:
> 
> # cryptsetup create main /dev/sda3

This is your problem. You need

cryptsetup -c aes-xts-plain -s 512 ...

every time you map this device. You can sort of avoid it by using the defaults,
which are listed at the end of

cryptsetup --help

However, if the defaults change, you need to remember those parameters.

This is a big advantage to LUKS, there is a header that remembers everything but
the password.

> # mount -t ext3 /dev/mapper/main /media/parabola
> 
> mount failed.
> 
> "If the password is not correct, the mount command will fail. In this
> case simply remove the map sdc1 (cryptsetup remove sdc1) and create it
> again." [1]
> 
> I'm sure that I was using the right password.
> 
> What is the problem?
> 
> [1] http://sleepyhead.de/howto/?href=cryptpart
> 
> Thanks
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> This is your problem. You need

> cryptsetup -c aes-xts-plain -s 512 ...

> every time you map this device.

Matthew, thank you so much.

I had a feeling that it might be connected with the command itself,
but I didn't try it because it seemed absurd.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

OK, let's go back to the recovery shell problem.
(That message is too big to place it here. Please use the archives.)

Looks like that it's not possible to use cryptsetup from a recovery shell.
What can I do to decrypt / mount my partitions after the boot?
(/dev/sda1 (/boot) is not encrypted.)

Thanks

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/25/2012 07:58 AM, Stayvoid wrote:
> OK, let's go back to the recovery shell problem.
> (That message is too big to place it here. Please use the archives.)
> 
> Looks like that it's not possible to use cryptsetup from a recovery shell.
> What can I do to decrypt / mount my partitions after the boot?
> (/dev/sda1 (/boot) is not encrypted.)
> 
> Thanks
>

What distribution are you using? That sounds odd because I'd think your recovery
shell is the same environment as your initrd which most certainly has cryptsetup.

If cryptsetup isn't working, try

# modprobe dm-crypt

(Although with recent kernels, this shouldn't be necessary anymore).

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> What distribution are you using? That sounds odd because I'd think your
> recovery
> shell is the same environment as your initrd which most certainly has
> cryptsetup.

Parabola GNU/Linux-libre [1].

> If cryptsetup isn't working, try
>
> # modprobe dm-crypt

FATAL: Module dm-crypt not found

[1] http://mtjm.eu/releases/parabola/parabola-mips64el-20120912.tar.bz2

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/25/2012 05:54 PM, Stayvoid wrote:
>> What distribution are you using? That sounds odd because I'd think your
>> recovery
>> shell is the same environment as your initrd which most certainly has
>> cryptsetup.
> 
> Parabola GNU/Linux-libre [1].
> 
>> If cryptsetup isn't working, try
>>
>> # modprobe dm-crypt
> 
> FATAL: Module dm-crypt not found
> 
> [1] http://mtjm.eu/releases/parabola/parabola-mips64el-20120912.tar.bz2

Ah, this is definitely an Arch Linux derivative. You need to add "encrypt" to
the HOOKS setting in /etc/mkinitcpio.conf and run (as root)

# mkinitcpio -p linux-libre

This will add cryptsetup and the necessary modules to your initramfs.

You also MUST add root=/dev/mapper/ROOT cryptdevice=/dev/sdX#:ROOT to your
kernel command line (/boot/grub/menu.lst for grub-legacy, /boot/grub/grub.cfg
for grub2). Where ROOT is whatever label you want and /dev/sdX# is your
encrypted block device. Furthermore, you need to set crypto= to your specific
settings, but I don't remember the format off the top of my head.

Are you *sure* you don't want to use LUKS? It will make your life a lot easier
(no crypt= kernel command line option, no need to specify ciphers and hashes
when mounting manually, etc...)

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> You need to add "encrypt" to
> the HOOKS setting in /etc/mkinitcpio.conf and run (as root)
>
> # mkinitcpio -p linux-libre
>
> This will add cryptsetup and the necessary modules to your initramfs.

It worked.

> You also MUST add root=/dev/mapper/ROOT cryptdevice=/dev/sdX#:ROOT to your
> kernel command line (/boot/grub/menu.lst for grub-legacy,
> /boot/grub/grub.cfg
> for grub2). Where ROOT is whatever label you want and /dev/sdX# is your
> encrypted block device. Furthermore, you need to set crypto= to your
> specific
> settings, but I don't remember the format off the top of my head.

I'd like to try mounting from a recovery shell.
But there is no /media. Is it possible to add it?

BTW, how to safely enable swap?
Should I chroot into the system and decrypt / swapon there?

> Are you *sure* you don't want to use LUKS?

Yes.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/26/2012 02:23 AM, Stayvoid wrote:
>> You need to add "encrypt" to
>> the HOOKS setting in /etc/mkinitcpio.conf and run (as root)
>>
>> # mkinitcpio -p linux-libre
>>
>> This will add cryptsetup and the necessary modules to your initramfs.
> 
> It worked.
> 
>> You also MUST add root=/dev/mapper/ROOT cryptdevice=/dev/sdX#:ROOT to your
>> kernel command line (/boot/grub/menu.lst for grub-legacy,
>> /boot/grub/grub.cfg
>> for grub2). Where ROOT is whatever label you want and /dev/sdX# is your
>> encrypted block device. Furthermore, you need to set crypto= to your
>> specific
>> settings, but I don't remember the format off the top of my head.
> 
> I'd like to try mounting from a recovery shell.
> But there is no /media. Is it possible to add it?
> 

You can mount to wherever you like. Once you've mapped the block device to
/dev/mapper/NAME, you have a block device like any other.

> BTW, how to safely enable swap?
> Should I chroot into the system and decrypt / swapon there?
> 

The easiest thing is probably a swap file. However, you can also have a separate
swap partition which gets encrypted with a random key each boot. You define it
in /etc/crypttab.

swap  /dev/sdX# /dev/urandom swap

This maps /dev/sdX# to /dev/mapper/swap with a random password. The "swap" in
the forth column tells /etc/rc.sysinit to run mkswap on the device after it's
mapped.

>> Are you *sure* you don't want to use LUKS?
> 
> Yes.

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> You can mount to wherever you like. Once you've mapped the block
> device to /dev/mapper/NAME, you have a block device like any other.

Will the following work from a recovery shell?

# mkdir media
# mount /dev/mapper/main /media
# mount -t proc none /media/proc
# mount --rbind /dev /media/dev
# mount --rbind /sys /media/sys
# mount /dev/sda1 /boot

There is no /bin/bash. Can I use ash?

# chroot /media /bin/ash

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> # mount /dev/sda1 /boot

Oops, /media is missing.

# mount /dev/sda1 /media/boot

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Matthew Monaco]

On 09/26/2012 04:49 AM, Stayvoid wrote:
>> You can mount to wherever you like. Once you've mapped the block
>> device to /dev/mapper/NAME, you have a block device like any other.
> 
> Will the following work from a recovery shell?
> 
> # mkdir media
> # mount /dev/mapper/main /media
> # mount -t proc none /media/proc
> # mount --rbind /dev /media/dev
> # mount --rbind /sys /media/sys
> # mount /dev/sda1 /boot
> 
> There is no /bin/bash. Can I use ash?
> 
> # chroot /media /bin/ash

Has it occurred to you to just try these things? We're getting a bit off topic
here...

That will work, assuming you mapped something to /dev/mapper/main with
cryptsetup already. Also, I think you meant /media/boot. Also, /mnt should be
available, no reason to insist on media.

ash is fine, it's what is provided by busybox in the initramfs.

I usually do:

# mount /dev/mapper/main /mnt
# mount /dev/sda1 /mnt/boot
# for m in dev proc sys; do mount --bind /$m /mnt/$m; done
# chroot /mnt

Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Stayvoid]

> We're getting a bit off topic here...

It's a bit off topic but related to dm-crypt. I guess that it's fine
to continue if it doesn't annoy anybody.

> Has it occurred to you to just try these things?

I tried and got the following message after the chroot command:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

I also tried to run /bin/ash in a recovery shell and got this one:

/bin/ash: can't access tty; job control turned off

I checked several threads regarding these errors. Looks like they can be
connected with various things. I decided to ask here because I feel
that my usage pattern is wrong.