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
> Status: ASSIGNED Any updates? This is definitely a nice feature to have.
considering this isnt anywhere in any vanilla package, and its support in Gentoo can be flaky at times, i dont think it makes any sense to have in official release media
Given last comment and that the bug was initially opened for evms, which was already dropped from the kernel specs and it's on its way out of the tree, I'm closing this as WONTFIX.