http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/linuxrc-loop_crypt.patch http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/initrd.scripts-loop_crypt.patch This just adds a loop_crypt boot option that if not-empty, should be the name of a cipher to be used by losetup, when present in the initramfs. For a key to be present, the livecd should have, in it's identifier /livecd, the name of the key. Hopefully will have a patch to make catalyst use it, meanwhile it's not useless. ps. learned bash just days ago, careful ;)
Cool. I've added both to SVN and they'll show up in the next genkernel. I can't wait to see the catalyst patch. ;]
(In reply to comment #1) Thanks, Now I'm having exams, but I promise to (hopefully) finish in August. I would've done it already, but I had to learn python just for this.
Not really... it could be done all in bash. The only thing you'd have to do in python is make it a valid value, which isn't that hard. Of course, now you know python, so it's not like you wasted your time. ;] File the catalyst patch (whenever you get to it) as a separate bug, please.
Oh no, this breaks the boot. (strange, I tested it at the time) He complains that "/init:790 unterminated quoted string"... but doesn't seem that simple. Busybox bug? Have to study, revert or help? So sorry! ps. For the record there's a lost "fi" (linuxrc line 593) and an extra "fi" (initrd.scripts line 114), but that's not it.
Did the lost and extra "fi" come from your patches or were they already there? Would you mind if I reverted this and we both looked at it together with Andrew Gaffney to see if we can figure out what's going on? I'll keep it in for now, and we'll revert it if wee need to do so. I really like this idea and would love to see it integrated, along with the capabilities from bug #162962 to also allow the key to reside on an external location (floppy/usb key/etc) into a single working patch, even if we have to do it in steps to get to that goal.
(In reply to comment #5) It's probably better. This will give me time to #Allow it to boot a fake system if key not present/wrong ;). #test luks vs. loop-aes performance and make the best choice #change to use raw keys instead of "gpg" ones (best right?) #change anything if necessary while doing the catalyst part ;). (No, the error is my fault, previous linuxrc tested fine. I got confident and did some changes just before posting :S).
Created attachment 122910 [details, diff] minor corrections Wait a sec, his patch is just for luks whereas mine now is for loopAES. If you're sure luks works ok with livecd's, could you let me know? Loop-aes was tested for Debian: http://lists.alioth.debian.org/pipermail/debian-live-devel/2007-February/000836.html Still, here's some corrections (but problem remains).
Created attachment 122988 [details, diff] problem fixed (boots ok now) Ok, I'm guessing nobody tried luks on cd's, so I'll implement the LUKS linuxrc to test/compare. Looks very easy, and that other bug/patch can also be applied with no changes. (All that is necessary is make sure startluks() is called later (for the cd), and after doing LUKS_ROOT_KEY="$(head -n 1 ${NEW_ROOT}/mnt/cdrom/livecd)" findkeymount() could set the LUKS_ROOT_KEYDEV, and then it's startluks).
Created attachment 123127 [details, diff] Luks version, without keys. Extra boot option for added security Please ignore last comments. Luks version tested, works great and code is much simpler. Added a new boot option "crypt_silent" that if set, will pretend not give away the fact it's encrypted, and should be used in conjunction with keys: if they're present it'll boot the system, if not it enters a shell quietly. This I believe is great to security, there's a chance the person won't realize encrypted data is there and will lose interest. It works for both livecd and hd boot. Anyone can start making livecd's in catalyst with this: http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/catalyst_luks_hack_0.1.tar.gz
Created attachment 123565 [details, diff] same as before + improved shutdown, left openluks clean for bug #162962 patch (crypt_silent this after)
I integrated this last patch along with 3 others I did, and send them as a set of git patches to wolf31o2.
inSVN
convert to open with keyword=InSVN
Please test genkernel 3.4.9_prer1 or better. This should be fixed now.
(In reply to comment #6) > This will give me time to > #test luks vs. loop-aes performance and make the best choice Performance or strength? loop-aes is the strongest encryption available. > #change to use raw keys instead of "gpg" ones (best right?) Or smartcard :) I will be happy to work with you on these... I tried to do this in current genkernel init script but it made it very complex, so unless a major cleanup will be applied, it would be very difficult to support all features (boot, splash, resume, encryption, user dialog). You can find an example from: http://wiki.tuxonice.net/EncryptedSwapAndRoot
(In reply to comment #15) > Performance or strength? > loop-aes is the strongest encryption available. Performance. Couldn't tell a difference, chose Luks since it was already included. > I will be happy to work with you on these... I tried to do this in current > genkernel init script but it made it very complex, so unless a major cleanup > will be applied, it would be very difficult to support all features (boot, > splash, resume, encryption, user dialog). Yes, indeed a major cleanup is required. See bug #189849, haven't reopened but maybe will. But other then that I think I finished this in the bug #162962. Splash works since user dialog is unnecessary (if key is found). Still if something goes wrong nothing happens, it should turn off splash then. I know nothing of resume stuff, but the guy in that bug did something on that, which I kept in my patch. > You can find an example from: > http://wiki.tuxonice.net/EncryptedSwapAndRoot > So all left to implement is a code-cleanup, smartcards and splash_off if decryption fails? Would you be interested in helping implement bug #189849? After that it would be trivial to add loop-aes and gnupg support. Cheers
