Bugzilla Bug 174294

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 an attachment (id=122910) [details]
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 an attachment (id=122988) [details]
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 an attachment (id=123127) [details]
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 an attachment (id=123565) [details]
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