Opps, here is the missing link:
http://wiki.gentoo.org/wiki/DM-Crypt

(I don't think it is a good idea to store the keyFile somewhere plain, [2] tells that there is support for crypt-gnupg, but it doesn't show any help how to setup it.

[2]: http://wiki.gentoo.org/wiki/Dracut

> You forgot the link to [1].
Already mailed but here again:
http://wiki.gentoo.org/wiki/DM-Crypt

> Never used loop-aes myself. Sorry if I miss the reason for your
> confusion because of it.
http://loop-aes.sourceforge.net

There is the source code. It needs patched util-linux(-ng) package to get working. Also you should not use (crypt-)loop because it conflicts with it (see README inside tar ball). It also provides a really simple swap encryption:

- /etc/fstab -
/dev/blaX none swap sw,loop=/dev/loop0,encryption=AES256,itercountk=100 0 0

This will make sure that everytime you bootup your system a new encryption is setup with an iteration of 100 (still performant enough for most things).

> Opening a dmcrypt volume creates a mapped block device in /dev/mapper.
> You treat it like a partition and format it with ext4. Unless you use
> some exotic flags for mke2fs, the journal will be put on the same block
> device and is encrypted along with the rest of it.
>
> So: No need to worry about it.
Thank you for the explanation. Maybe it should be added to the wiki?

>
> Hope this helps,
> Florian Philipp
Sure it does.

Roland

> No comment on dracut as I have no experience with it.
Okay, so I have to try it out myself. When I found something out, I expand the wiki with it.

>
> However, as I see it, you need no key file if you just use a pass
> phrase. In my opinion, a key file is only necessary for two improvements:
Entering just a pass phrase means that this pass phrase will be used to decrypt the device, if you decrypt a key before and then with that key decrypt all your volumes you have a much better security because that key will then be used as 'pass phrase' which is *way* much stronger (4096+ chars + ~10-20 chars you can remember).

>
> 1. Two-factor authentication (read: encrypted key file)
>
> 2. Avoiding re-typing the pass phrase for multiple dmcrypt partitions
See above.

> You can easily achieve the second point by putting an unencrypted key
> file on the first partition which you encrypt with a pass phrase. You
> don't even need dracut for this, /etc/conf.d/dmcrypt lets you configure
> it easily (as long as it doesn't affect /usr).
Okay, I look into this.

>
> However, I personally find it easier to put LVM on a single dmcrypt
> volume and be done this. All you need for this to work are two lines in
> /etc/rc.conf:
> rc_dmcrypt_before="lvm"
> rc_dmcrypt_after="udev"
I'm new to LVM, does it setup key-based encryption (best is to put that key on an USB stick, so the attacker needs my stick).

Regards,
Roland

Okay, I have made a little progress. I have generated my private key using some random data + gpg:

# head -c 3705 /dev/urandom | head -n 66 | tail -n 65 > key.out
# gpg --symmetric -a --s2k-count 8388608 key.out
<Enter your password twice>
# mv key.out.asc key.gpg
# rm -f key.out

Now I have to copy that file on my stick and setup /etc/conf.d/dmcrypt:

# whole root system encrypted with gpg key from removeable media
target=crypt-root
source='/dev/hdaX'
key='/key:gpg'
# This is your stick
remdev='/dev/sda1'

But what next? The example at [1] is based on key-only file (no passphrase). I know, later on /etc/conf.d/dmcrypt must be placed on the new root-fs but what now? I still have to setup it. cryptsetup doesn't do anything with gpg. So I have setup a pipeline?

I think I made a (tollerateable) mistake:

My hard drive has two partitions:
- sda1 - encrypted swap
- sda2 - encrypted root

How should it boot? One way could be by external media (e.g. stick), other is from hard drive. But that is encrypted. So I must leave a small area left for kernel, initrd, System.map and maybe config.

So the page at [1] is a little wrong because it misses the boot partition, so the new layout should be:
- sda1 - unencrypted boot (/boot) partition
- sda2 - encrypted swap (at least as double as your RAM) (crypt-swap)
- sda3 - encrypted root (crypt-root)

Can someone update this?

Regards,
Roland

[1]: http://wiki.gentoo.org/wiki/DM-Crypt

"Roland Häder" wrote:
> - sda2 - encrypted swap (at least as double as your RAM) (crypt-swap)
>
> Regards,
> Roland
>
> [1]: http://wiki.gentoo.org/wiki/DM-Crypt
>
>

I don't think this is true anymore. It was back when machines had small
amounts of ram. Case in point, I have 16Gbs of ram. If I have a
program that needs more than that, I need a bigger machine anyway.
Since ram has got so large, and cheap, I always make my swap around 1Gb
or so. If something does run away and eat up ram, I got enough swap
that I have time to kill it. I would not make a 32Gb swap partition
tho. That would slow about any machine to a crawl if it starts using
that much.

I think the new method for determining swap is to use what makes sense
and not the old rule of 'twice the ram'.

Hope that helps.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

> I think the new method for determining swap is to use what makes sense
> and not the old rule of 'twice the ram'.
Okay, agreed.

Roland

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04.09.2012 15:48, "Roland Häder" wrote:
> I think I made a (tollerateable) mistake:
>
> My hard drive has two partitions: - sda1 - encrypted swap - sda2 -
> encrypted root
>
> How should it boot? One way could be by external media (e.g.
> stick), other is from hard drive. But that is encrypted. So I must
> leave a small area left for kernel, initrd, System.map and maybe
> config.
>
> So the page at [1] is a little wrong because it misses the boot
> partition, so the new layout should be: - sda1 - unencrypted boot
> (/boot) partition - sda2 - encrypted swap (at least as double as
> your RAM) (crypt-swap) - sda3 - encrypted root (crypt-root)
>
> Can someone update this?
>
> Regards, Roland
>
> [1]: http://wiki.gentoo.org/wiki/DM-Crypt
>

In theory grub2 is able to open a luks-encrypted volume though it
seems to have some disadvantages: you'll need to enter the passphrase
(or pass the keyfile) two times, because grub itself needs to decrypt
the volume to get the later stages from the encrypted volume and
afterwards the decryption in the bootprocess itself takes place.

I can't give any real advice about it though, because I use an
unencrypted boot partition. Depending on your needs it could be an
increase of security, because you can stop an attacker from injecting
malicious code into your kernel (or replace it completely).

WKR
Hinnerk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQRjxMAAoJEJwwOFaNFkYcWfcIAJvh9CxmlP eWTlJ8qMMb24tf
8tCVPo7FjnELrOqHwccqRceC1/1kIfjfYy0BowbRBOAV49WEIt3WWZhySVcS5PzH
mh30OVZZ1Gb94QjwUSoKb+4FfULpM8oVp3kpaxf11Ls7SlJgRk W4hiSNmEWGt/2Q
RRgTQpkFp7W6b1sWnbnKY491iCsL657G90UK7lKe3qe15u7V0E 8bY2XvzJrPSf4E
K3V0mpHunLWDMbr0lfoezbeOEuqSfRdUlgQWw3Q4iCKBxFX5hh 9ac5T8cne4xUJ7
OKp6HAYE3sl8othQ+ngMNVyu/vX6j0dCtZHgPtAZEDU1pjE33rjiaLXm15aCVbU=
=AG8l
-----END PGP SIGNATURE-----

> In theory grub2 is able to open a luks-encrypted volume though it
> seems to have some disadvantages: you'll need to enter the passphrase
> (or pass the keyfile) two times, because grub itself needs to decrypt
> the volume to get the later stages from the encrypted volume and
> afterwards the decryption in the bootprocess itself takes place.
>
> I can't give any real advice about it though, because I use an
> unencrypted boot partition. Depending on your needs it could be an
> increase of security, because you can stop an attacker from injecting
> malicious code into your kernel (or replace it completely).

I don't think so, I still can replace your bootloader and grab your
password. If you really think you might need something like this, I
suggest you put your kernel and bootloader on a USB stick and boot your
machine from that. When not in use keep the stick on your person.

That still does not protect you from physically tempering with your device.

Anyway, what about one those fancy tin foil hats to protect oneself
against the governments mind control rays

> 1. Maybe it would be a good idea to use an ASCII-only random string, for
> example by piping it through `base64 -w 0`. That way you don't loose any
> entropy (the key just gets longer) but it is easier to type the keyfile
> manually, in case you ever need to. You also don't have to worry about
> odd behavior of password prompts anymore.
I think that is now to late for? I have already formated it and added ext4 on it plus installed some packages already (was a long way).

>
> 2. You should `shred` key.out instead of `rm`.
That key file was on RAM disk, not on real.

Roland