Description of problem: after the last cryptsetup-luks update, I can no longer login to my box. I have setup a encrypted partition for my desktop user using this tutorial and cryptsetup/pam_mount: http://forums.gentoo.org/viewtopic-t-274651.html It doesn't use Luks. Version-Release number of selected component (if applicable): cryptsetup-luks-1.0.5-4.fc7.1 How reproducible: Steps to Reproduce: 1. Use the tutorial to setup either an encrypted loop mounted file or real partition for some user. 2. Login as this user 3. Upgrade to the latest cryptsetup-luks for F7 Actual results: You can not login, I get a message related to an unknown HFS+ partition (the real one is an ext3 partition) Expected results: You should be able to login, just like before the upgrade. Additional info: http://forums.gentoo.org/viewtopic-t-274651.html
If I just need to setup my encrypted home partitions in a different way please let me know.
I use pam_mount with luks volumes and this works flawlessly. Can you describe you setup with more detail, e.g. what is the volume entry in you pam_mount.conf and what ciphers did you use and which version of cryptsetup to setup your encrypted partitions? Can you open your encrypted partitions manually?
Till, These are my volume entries: volume jeroen crypt - /dev/Goliath/jeroen /home/jeroen cipher=aes aes-256-ecb /m edia/disk/keys/jeroen.key volume root crypt - /dev/Goliath/root /root cipher=aes aes-256-ecb /media/disk/k eys/root.key Both don't work with the latest cryptsetup-luks anymore. I have no idea which version of cryptsetup I used to setup these volumes initially . Have used this setup for some time now, for the first time with FC4. The setup is like this: Keys are on a compact flash card I connect using a cardreader. Volumes are plain cryptsetup (non Luks), cyphers are aes aes-256-ecb. As we speak I have everything working with cryptsetup-luks-1.0.3-4.fc7.
Can you paste the output of "dmsetup table" (run as root) for the encrypted partitions you use? BEWARE: make sure, that there are only a lot of 0 in the line, like here: otherwise you would post your secret key here. Anyway, the only interesting part here for me is the 5th column, in this example "aes-cbc-plain". foo: 0 20480 crypt aes-cbc-plain 0000000000000000000000000000000000000000000000000000000000000000 0 7:0 0 Btw. I strongly recommend to change your setup, there are more secure alternatives to aes-256-ecb, e.g. aes-256-cbc and I read that there is even a stronger mode thatn cbc available, lrw. There may be other issues, depending on the output of dmsetup table, so you should upgrade to using luks and a better encryption and hashing method, anyways.
_dev_Goliath_jeroen: 0 12582912 crypt aes-cbc-plain 0000000000000000000000000000000000000000000000000000000000000000 0 253:8 0 _dev_Goliath_root: 0 4194304 crypt aes-cbc-plain 0000000000000000000000000000000000000000000000000000000000000000 0 253:9 0 Thanks for the tip, will look into that, any pointers to a good tutorial on that?
I did some testing now, it seems that the old cryptsetup created a different encryption key, depending on whether the key was sent via stdin or entered manually. I saw this when using this key "k<@4O[T)QK,G9XXH),rqkg9DP@(|@ZP|}o*S`de>XgQ?.4M,{KA#!8s@We0yR|1|S`~rGf}Sq5R*iuS" When I use a simpler passphrase, e.g. "test", then encryption key is the same when I manually enter it and when it is read by stdin. I can provide you instructions on how you can convert your setup, that it should work with both, your old and new setup, but it requires a patch to pam_mount[1], when the key that is used by cryptsetup contains a newline character. Btw. I was wrong with my recommendation to upgrade previously, because you use cbc and not ebc for the encryption of your devices. But luks still provides some security improvements. So you may want to uprade, anyway. But I would wait until the pam_mount patch god some feedback and is available in Fedora. When I get positive feedback, I will create a new pam_mount package, soon. I do not know a good english guide, but maybe I will write something up and add it to the Gentoo wiki. From the German Gentoo wiki I got the information about lrw btw. [1]http://sourceforge.net/mailarchive/forum.php?thread_name=200709071542.58189.opensource%40till.name&forum_name=pam-mount-user
Thank you very much for your work sofar. I did see your post on the pam_mount mailinglist. Such a pitty pam_mount did not provide me with good info (debug on), so I could figure that one out on my own, but I guess that's just the way old style cryptsetup works. That is: your passphrase either unlocks your current volume or it creates a new one on the fly, I guess that's another reason to convert to Luks. Anyway I don't have the time today, but if you provide me with some info I'm happy to test things out later. Btw are you sure pam_mount is to blame, the way I see it the only thing that changed and breaked my setup is cryptsetup-luks.
(In reply to comment #7) > Anyway I don't have the time today, but if you provide me with some info I'm > happy to test things out later. Btw are you sure pam_mount is to blame, the way > I see it the only thing that changed and breaked my setup is cryptsetup-luks. Yes, it is cryptsetup that broke it, but afaics because the old version of cryptsetup were buggy. Imho the current cryptsetup behaviour is more sane. But the problem is, that the interface pam_mount uses to interact with cryptsetup is only intended to be used for passwords but not binary data. But I only found a way to create a binary key file for cryptsetup, which cannot be send to cryptsetup via pam_mount currently. Here is the way how you should be able to use your encrypted partitions with the new (and old) cryptsetup and a patched pam_mount: 1) dmsetup --show-keys table after your partitions are mounted. Now remember the long hex string that contains the raw encryption keys for the partitions, that you need for the next step. 2) run "echo -n '<hexkey>' | xxd -r -p | openssl aes-256-ecb > new.key Here you need to enter the user password, like it was described in the Gentoo tutorial. 3) edit your pam_mount config to: volume jeroen crypt - /dev/Goliath/jeroen /home/jeroen cipher=aes,hash=plain,keyfile aes-256-ecb /m edia/disk/keys/jeroen_new.key volume root crypt - /dev/Goliath/root /root cipher=aes,hash=plain,keyfile aes-256-ecb /media/disk/keys/root_new.key Now it should work with the new cryptsetup, too. I did not try the complete procedure here locally, so it may not work for you or even break something. But since the new cryptsetup did not break any data with the wrong key, I guess there should not happen anything. But please backup your data first.
Could you please attach the patch with instructions on how to apply it, so I can test this.
Today I had the time to work on this again (I was kind of ill recently). I may have found out, what really is the problem here, cryptsetup-1.0.3 only used 32 bytes of your keyfile, but according to the gentoo guide, the key contains 79 bytes: | KEY=`tr -cd [:graph:] < /dev/urandom | head -c 79` 1) openssl aes-256-ecb -d -in /media/disk/keys/jeroen.key -out jeroen_new.key.decrypted 2) head -c 32 jeroen.key.decrypted | openssl aes-256-ecb > /media/disk/keys/jeroen_new.key Make sure here, that you do not store jeroen.key.decrypted on an unencrypted filesystem. Enter your login password when asked and use /media/disk/keys/jeroen_new.key in you pam_mount config instead of /media/disk/keys/jeroen.key You can first try, whether this works with cryptsetup-1.0.3 before you try 1.0.5. You can test this without using pam_mount with: openssl aes-256-ecb -d < /media/disk/keys/jeroen_new.key| cryptsetup create ctest /dev/Goliath/jeroen and then try to mount /dev/mapper/ctest: mount -o ro /dev/mapper/ctest /home/jeroen
Thank you very much, this works just fine (both with the old and with the updated cryptsetup-luks voor F7)