Bugzilla Bug 77695

Installing gentoo on an encrypted (evms) root device is currently quite
burdensome as the live cd kernel does not support loop-aes.

I suggest adding an alterative kernel with loop-aes loop and cipher
modules so that a direct installation on an encrypted possibly evms/lvm
backed root device is possible.

You're welcome to contact me for feedback or questions.

Reproducible: Always
Steps to Reproduce:

Well, I hinted at this before, but we don't have the cryptoloop module for a
reason.  Instead, we recommend using dm-crypt for building an encrypted loop.

Now, if you want to give specifics on how you think it should be done and can
come up with a solution that does not remove current functionality, then I'm
all for adding it.

I do not see a "loop-aes" anywhere in the 2.6.10 configuration.  Is this a
separate kernel patch that is needed or am I just missing something?

There are some people which prefer loop-aes to dm-crypt for various reasons.

loop-aes can be built as separate kernel module without patching the kernel.
However, it is important that CONFIG_BLK_DEV_LOOP=n. Note that loop-aes
requires a patch for util-linux (mount, umount, losetup, swapon and swapoff)
which also seems to be available as gentoo package (version 2.12p).
The sources can be found here: http://loop-aes.sourceforge.net/

Apart from the main loop-aes package, there is a package called ciphers
which contains additional ciphers, e.g. serpent. This should also be
included on the live cd.

The aespipe package contains a user space program which is also
available as gentoo package.


My suggestion for integrating loop-aes on the gentoo live cd would be
to add the user space tools to the cd as described above (the util-linux
patch should not hurt dm-crypt or normal loop usage). As for the kernel,
I suggest adding an additional kernel image for loop-aes as it is
incompatible with the standard loop module.

Also, we're not going to go to a dual-kernel configuration, especially for a
single feature.  If this can't play nicely in a single-kernel configuration,
then I'm going to WONTFIX it, especially considering that the LiveCD itself
requires the standard loop module to boot.

Alright... loop-aes has been added to portage, though it is a bit late to make
it into this release.

Waiting for this to go atable before inclusion... it'll be 2005.1

I'm not sure about loop-aes but you could use dm-crypt instead as described in 

http://axljab.homelinux.org/Encryption_-_dm-crypt

you can use livecd 2005.0 to rescue/instantiate an ecrypted partition.

however, in the LiveCD, first type

modprobe aes
modprobe sha256
modprobe dm-mod

to load needed modules. cryptsetup tools are already included in livecd.

I've already testd it on my machine and with liveCD 2005.0, I was able to access
an encrypted partition created as described in the url above.

-Bedros

Thanks for your reply Bedros. I am aware that dm-crypt can be used out of
the box with livecd 2005.0. However, I really wanted (and still want) to
use loop-aes instead.

Therefore, I have modified the 2005.0 livecd such that evms + loop-aes is
supported. The installation worked perfectly.

Still isn't marked stable, so it looks like it'll be 2006.0 before we add this
support.

A chance for 2006.1?

Not anymore...

So a chance for 2006.2? :)

Nope.  2007.0, only because there won't be a 2006.2 release.

So you will add loop-aes in next release? Whatever its number will be... It
will make some very happy! :)

In order to allow people to handle their encrypted file-systems, you need the
following packages:

sys-apps/util-linux USE: crypt
sys-fs/loop-aes
app-crypt/aespipe

Thanks!

Only if everything is stable...

Everything is stable :)

People will be able to use the Live-CD in order to setup encrypted system, and
as a recovery tool.

Thanks!

err... yes, once we make a new CD with this on it.

loop-AES seems superior to dm-crypt/LUKS because it can handle complete disks
(so partition tables aren't exposed) and doesn't store the key on the encrypted
device (which is the single-most-stupid "feature" of LUKS). No doubt, I'd
prefer to use loop-AES on my systems :-)

(In reply to comment #17)
> loop-AES seems superior to dm-crypt/LUKS because it can handle complete disks
> (so partition tables aren't exposed) and doesn't store the key on the encrypted
> device (which is the single-most-stupid "feature" of LUKS). No doubt, I'd
> prefer to use loop-AES on my systems :-)
> 

little do you know loop-aes is not consider to be use in the kernel and
cryptsetup-luks has the option to use a gpg encrypted key which can be located
anywhere. also with dmcrypt you can attach a file to loopback and then run
dm-crypt on top of that, so I think it's completely duplicate functionality at
this point. Again, cryptoloop is the claim that it is insufficiently secure &
it's (mis)leading our users into thinking that their data is secure.
Cryptoloop is deprecated (since 2.6.4) so get with the program :D

(In reply to comment #18)
> little do you know loop-aes is not consider to be use in the kernel and

Well... I don't know why you make such definite statements...
But Multi-key-v3 of loop-aes is the strongest encryption method currently
available.

(In reply to comment #19)
> (In reply to comment #18)
> > little do you know loop-aes is not consider to be use in the kernel and
> 
> Well... I don't know why you make such definite statements...
> But Multi-key-v3 of loop-aes is the strongest encryption method currently
> available.
> 

true but I still prefer to use device-mapper instead of cryptoloop. please luks
provides multiple key slots but i only use it with certain partitions the rest
are using gpg/openssl encrypted keys.

So why are you commenting anything in this bug?
This bug is to add support for loop-aes, not discuss what is better for you or
to anyone else.

(In reply to comment #21)
> So why are you commenting anything in this bug?

I was commenting on Robert's quote nothing more, I on topic i don't see why
Gentoo would ever pick cryptoloop device over device-mapper since it's not
recommended by the kernel maintainers at best and since loop-aes requires
cryptoloop which conflicts with device-mapper. anyways, i'm done defending
device-mapper. so please don't even start with me again. :D

release: Any target for this one?

release: There is a lot of time until next release, please consider adding
this. It will help users that wish to install their software on encrypted
devices.

If there is something missing please say so, so I will have a chance to fix it.

I'll add this to the 2008.0 specs as soon as I get a chance.

Thanks!

The following packages are needed:

Support for losetup and mount:
<sys-apps/util-linux-2.13.0.1 USE: crypt (STABLE)
>=sys-apps/util-linux-2.13.0.1 USE: loop-aes

Kernel loop replacement, support encryption in multikey mode:
sys-fs/loop-aes

Small utility, used to encrypt/decrypt/reencrypt volumes:
app-crypt/aespipe

So sys-fs/loop-aes is only stable on x86?

Yes.
Never requested for other arch...

I submitted a request for amd64, bug#214161.

Do we need more?

Well, ideally, we'd have them all.  At minimum, we should have the same as
aespipe.

(In reply to comment #29)
> Well, ideally, we'd have them all.  At minimum, we should have the same as
> aespipe.

I don't understand... Why is there a dependency between the release and the
aespipe components?

aespipe is good as user mode application to decrypt/encrypt entire partition.
This is good for recovery and/or boostrap. So it would be great if it will be
available even if loop-aes will not be available.

Hi!

I managed it to build my own gentoo live cd with loop-aes support. I used
catalyst and the gentoo-livecd 2008 specs. I could share specs and
instructions, or the image (amd64) if of interest.

regrards bjoern