Um, that is the symptom that happens when the passphrase is wrong, or when the incorrect encryption algorithm is on the mount (like AES126 when the file system was encrypted with AES256, or blowfish, or whatever).

Not good knews. When that happened to me I messed up the pass phrase when encrypting, I had to restore from a backup and CAREFULLY reencrypt the partition. Sorry.

Chadders

P.S. You might think about using the device mapper dm-crypt instead of loop-AES. Other threads can tell you why.

First, if I understand the security howto's correctly, one should password protect their BIOS and boot from an internal hard drive to prevent a user from popping in a CD or floppy and booting their own system. If I had a laptop and some nefarious individual got a hold of it they could easily wipe by nice encrypted system from my hard drive. They could probably circumvent the BIOS too but it adds a layer of security and I'm paranoid .
Same is true I suppose for a locked desktop PC. So what is wrong with this or is there a better way to protect the data then boot from USB/CD/Floppy?

Im no encryption expert and have been checking around myself and this is what i can find out.
Cryptoloop is a nohope solution securitywhipes, atleast for those that lack uberlinux skills(and perhaps can avoid some of the vulnerabilitys otherwise).
dm-crypt is a big questionmark. Ive read some about a patch that can be used with dm-crypt by using certain commands at install. This patch salts dm somehow making it more secure agains watermark.Some kind of ESSIV story.
Loop-aes seems to be the only really renowned secure solution atm(with multikeys), but seems to be a bitch to get working.

Tried to get more opinions about the dm-crypt voulnerability issue, but no luck so far.
I am kinda fresh at using linux(except for my webserver, but any dufus are probably able to install a apache/php/mysql solution today) and prefer to get an easy solution to this. But installing encryption that isnt moderatly safe is to me like making something not working, totally pointless. So would be nice with more input.

I have a problem with my passphrase, recently i have use one that have 'A' and 'M' characters. So what's the problem ? well, when i'm taping my passphrase under knoppix, my keyboard is 'azerty', but once i boot my crypted root, my initrd seems to be in 'qwerty'. Is there a way to tell initrd that i'm using an 'azerty' keyboard ?

I've been encrypting an existing root filesystem, on amd64, with udev. Just different enough that none of the docs quite match. :->

1. cryptoloop and dm_crypt are currently deprecated for lack-of-security reasons. You will find that the options to turn them on are disabled in recent 2.6 kernels. So loop-AES is defintitely the way to go.

2. The ldd in recent versions of Gentoo (and other bleeding-edge distros) changed its output format, which breaks loop-AES's build_initrd.sh script. There is a one-line patch here:

does this guide still ring true? it is sort of old. I am looking at doing this right now my self. However I wish Trusted Gentoo wasn't just vapor ware because i could have used my tcpa chip for storing the keys.

I did Example 5, Encrypting Root Partition. Encrypting a non-root partition is easy -- I recommend doing that first for practice before moving on to the harder cases. (If you don't have a spare partition, you can always disable swap and then mess around with your swap partition.) The root is a pain because of having to set up initrd, make sure the necessarily devices are visible early enough in the boot process, make sure things are compiled statically so they work without /usr/lib available, etc. Anything you do wrong usually hangs the system and renders it unbootable, and then it's back to Knoppix or the Gentoo livecd.

Never did get it working correctly with udev -- I had to revert my system to devfs, which has explicit support instructions. Not saying udev can't be made to work, just that I couldn't get it working before running out of patience.

I used the latest versions of loop-AES, aespipe, util-linux, and gpg, all built by hand under /usr/src rather than using portage. For dietlibc I just used the ebuild.
Other than the one-line patch to build-initrd.sh to work around ldd's output changing in recent glibc versions (see my other post), there were no big surprises. It's just a matter of getting all the little steps right at the same time.

Anyone who knows enough about this bit, this question is directed to you - my roommate told me, at one point, not to emerge and update my bin-utils EVER. But the version I use is no longer in portage. Is there a real reason I can't update, or should I be good to go?

Anyone who knows enough about this bit, this question is directed to you - my roommate told me, at one point, not to emerge and update my bin-utils EVER. But the version I use is no longer in portage. Is there a real reason I can't update, or should I be good to go?

I wouldn't do it. I haven't updated them and haven't run into problems... yet...
So if it ain't broke don't fix it.

i intent to encrypt my notebook's partitions using aes-loop but i have one question:
would it ...
...be technically possible to use a TPM chip (trusted platfrom module) to create and store the encryption key?
...make any sense securitywise? as the key would be stroed in the TPM instead on an unencrypted partition

please tell me if this is complete bull****, aside from the fact that tpm's aren't very popular with the open-source-crowd.

I've encrypted my root partition following the steps in this howto, everything worked
I'm using udev (configuration as in "without devfs" comments in build-initrd.sh), portage loop-aes, util-linux (with crypt and static) useflag, aespipe (static useflag) and gpg (compiled myself, since it doesn't have a static useflag).
There's one caveat though: the aespipe version marked as stable in portage (2.2a) doesn't support multi-keys. After I initially encrypted my partition, I wasn't able to mount it (got losetup'ed properly though). I just piped the data on the disk back through aespipe to decrypt (which worked like a charm), emerged ~x86 aespipe and re-encrypted the data. I suppose this might also be the reason for most of the "wrong fs type" errors posted in this thread.

Fine tut! I was looking for something like this for some time. I'll try it on a virtual machine before diving on my real PC._________________A mind that is stretched by a new experience can never go back to its old dimensions. - Oliver Wendell Holmes

1. cryptoloop and dm_crypt are currently deprecated for lack-of-security reasons. You will find that the options to turn them on are disabled in recent 2.6 kernels. So loop-AES is defintitely the way to go.

Cryptoloop IS deprecated, but dm_crypt ?? There's no mentioning of any security risks in the 2.6 Kernel, and it's definately not deprecated. It WAS susceptible to watermarking attacks with the old public-IV mode, but since ESSIV got introduced with 2.6.10 that issue was erased. I'm just a layman, but if I understand correctly, ESSIV in dm-crypt is the equivalent (security wise) to multi-key mode in loop-AES. Further information here.
So regarding security issues, both seem to be on the same level.

Nevertheless I have gotten the perception from reading mailing lists & other forums about this topic, that dm-crypt in combination with LUKS is considered superior to loop-AES, mainly because of its key management & especially design issues.

The doc was nice and easy to follow, but I must of missed something. I have encrypted the Drive and setup the ramdisk and all the kernel stuff. When the Kernel starts loading it Stops half way, and says:

If I had a laptop and some nefarious individual got a hold of it they could easily wipe by nice encrypted system from my hard drive. They could probably circumvent the BIOS too but it adds a layer of security and I'm paranoid .

Moden laptop BIOS passwords cannot be reset. You have to send the laptop in to a service center to have this done (requires BIOS replacement).