http://blog.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2865 I'm concerned about the security of my data (obviously or I wouldn't be here), but I don't understand what happens to keys when I close the volume. I am using Ubuntu with cryptsetup. I use the command "sudo cryptsetup luksOpen /BLOCK/DEVICE encrypt && sudo mount /dev/mapper/encrypt /mount/location". I'm not really sure what these commands do, but more specifically what the closing command: "sudo umount /mount/location && sudo cryptsetup lukClose /dev/mapper/encrypt". I believe that luksOpen just decrypts a header that has the actual random encryption key and volume info. It then creates a new device that basically tells the system that decryption is needed before anything can be read/written. That all seems very straight foreward, but what happens when it closes? Does it do more than delete /dev/mapper/encrypt? I would hope that it writes over the key in memory. Is that right? If not, is there some way to make sure that the key is wiped? Thanks, Justin Brown justin.brown1.1-Re5JQEeQqe8AvxtiuMw justin 2008-09-25T15:55:45 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2856 i try to install windows on my linux (Debian) so i was play arround with my partition table, i have a luks partition on logical drive /dev/sda7 (45 gb). so i format another logical partition of the same driver with ntfs so i can install windows, but windows cannot install on a logical partition, so i use testdisk and a change the last logical partition and i put it like primary, of course that was wrong because the /dev/sda2 was configured to use all the remaining cyls like logical partition well when i realize that i put back my logical partition with testdisk and now when i try to mount my luks partition y said that my luks password doesn't work. this is what cryptsetup luksDump /dev/sda7 showsme Version: 1 Cipher name: aes Cipher mode: cbc-plain Hash spec: sha1 Payload offset: 1032 MK bits: 128 MK digest: a3 8b 97 7c d2 0b f1 a9 82 30 87 a7 bf 40 c0 73 39 c4 c3 45 MK salt: 2e 28 b5 5d 2e 91 2e f8 5a 1a e0 e5 af e8 13 16 91 66 03 25 b2 4d ef 75 3c d0 a0 nicolas-PI3JibxLp+rn7EPgIJJ5S1AUjnlXr6A1< at >public.gmane.org 2008-09-23T12:36:56 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2855 Hello, I'm new to the list. I have a crypt device needs to be reliably unmounted and secured and I'd like to avoid shutting down. Heres what I'm doing in bash to deal with failed commands: cd /dev/mapper fuser -km crypt-foo umount crypt-foo || umount -l crypt-foo cryptsetup luksClose crypt-foo || rm -f crypt-foo crypt-swap || halt When it fails on cryptsetup and succeeds at "rm -f crypt-foo", is is the device secure? Meaning it cannot be accessed without entering the key again. This is not counting data that may have been read from the device and left in memory. I assume powering off makes it secure, is that right? Any suggestions? - Drew Ian Kelling 2008-09-23T07:37:46 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2848 By googling I found a lot of mention of backing up a LUKS header with a simple dd command (ie dd if=/dev/hda2 of=luksheader count=1032), as well as discussions on plausible deniability issues because of the existence of the header. This presented me with two questions: 1. According to http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq it seems like it should be easy for a user who has legitimate access (ie his own password) to the LUKS device to backup the header, that way, when his key is revoked he can simply put the old header back to regain access. Wouldn't that defeat the whole purpose of key management / password revocation? How do you avoid this? 2. I know that that same LUKS FAQ page warns severely against managing your own header file, as it is very hard to keep it off of managed magnetic medium and maintain control of the physical token, but given proper care it seems like this could effectively solve the plausible deniability problem as well as, potentially, header backups. I, howeve Clayton Shepard 2008-09-17T23:10:13 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2827 Hi users, Dear contributors, cryptsetup is changing to the Google Code Hosting Service. The new project home is http://code.google.com/p/cryptsetup/ The reason is that managed services are less work to me. Also it provides me with an issue manager that allows me to track issues over longer periods of time. I felt this to be necessary as I'm not constantly working on cryptsetup and I'd like to avoid that an issue slips my attention. Please refer to http://code.google.com/p/cryptsetup/source/checkout for svn checkout instructions. You can subscribe to this feed if you are interested in tracking changes http://code.google.com/feeds/p/cryptsetup/svnchanges/basic For commit access to the repository having a Google account is necessary (I'm sorry for that, but the Google TOS is not that evil, however if you object the TOS, there is still the options to send patches to me directly). Thanks, -- Fruhwirth Clemens - http://clemens.endorphin.org Clemens Fruhwirth 2008-09-16T09:59:52 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2824 Hello List! I ve a running software raid system with a few raid1 and some raid5 partitions. Those are luks encrypted using gpg keys. /dev/md2 (raid1) works fine and prints the luks header. /dev/md3 (raid1) works fine but doesnt print a header? Even hexdump cant find any trace of a header... How is this possible? /dev/md4 (raid5) doesnt work anymore and the header is also missing. But it worked yesterday... Everything worked up to some point. Whats going on here? I cant manually decrypt the partitions. The only way to decrypt the 2 still working ones is by restarting my gentoo system and letting the startup scripts handle the decrypt. Any idea? Thanks in advance. Jan Marc Hoffmann Jan Marc Hoffmann 2008-09-11T23:19:28 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2822 Hello. I'll tell it simple: we want vmpc encryption in dm-crypt (especially vmpc-ksa3)! ;D What is vmpc - http://www.szyfrowanie.com/tech_e.htm Thx DeSnajpa_VI Tomasz Sieprawski 2008-09-10T17:01:15 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2805 Hi, About two months ago, there was a message here about whether dm-crypt uses more than one core to do encryption. I did some experimenting with kernel 2.6.26.3, and it seems that dm-crypt uses one core per device. How difficult would it be to adjust dm-crypt so that it splits crypto operations for one device evenly across the available CPUs? I noticed that dm-crypt was recently converted to use the async support in the Linux crypto library. I guess this is the first step to getting true multicore support working? Is there anything I can do to help with this? Andrew Miklas 2008-09-06T01:57:46 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2804 Hi Clemens & all, recently was in cryptsetup introduced udevadm (udevsettle) call. That solved some problems, but introduced many others: - if cryptsetup is started through udev rules, it deadlocks (waiting for itself) and need full timeout to recover (180 or 30 seconds) - if udevd is not running yet (early installation, recovery, etc) it waits for this timeout too - it waits for other devices changes unnecessarily. why it should wait for all disc to settle? - using system() call in software like cryptsetup should be avoided IMHO the udev command introduction is the not good idea. I tried to install Fedora recently, using 3 encrypted logical volumes. Every volume, two udevsettle calls, 6 x 180 timeout. Unusable without manually kill the udevsettle process! What's the problem - udev triggers activation of temporary-cryptsetup-$PID device, keeping it open. So meaning of udevsettle is to ensure that all udev scanning is done and no process has this temporary device open. (So it is problem of wrong ude Milan Broz 2008-09-04T13:24:05 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2803 Hi Clemens, please could you apply this to upstream cryptsetup? Thanks, Milan -- mbroz-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org --- Fix signal handler to proper close device, otherwise if the descriptor is 0, it keeps device open and temporary-cryptsetup-$PID mapping is not removed (leaving device open and unusable). --- luks/keyencryption.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) Index: cryptsetup.my/luks/keyencryption.c =================================================================== --- cryptsetup.my.orig/luks/keyencryption.c2008-09-03 13:26:53.000000000 +0200 +++ cryptsetup.my/luks/keyencryption.c2008-09-03 13:27:31.000000000 +0200 < at >< at > -97,12 +97,13 < at >< at > static int clear_mapping(const char *nam /* I miss closures in C! */ static struct setup_backend *cleaner_backend=NULL; static const char *cleaner_name=NULL; -static int devfd=0; +static int devfd=-1; static void sigint_handler(int sig) { - if(devfd) + if(devfd >= 0) close(devfd); + Milan Broz 2008-09-03T12:10:28 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2802 Hello, I forward the following message to dm-crypt-4q3lyFh4P1jhvxM+mQhndA< at >public.gmane.org It might be interesting to everyone who uses or is interested in the XTS mode. in case that it the document in question is no longer available from the IEEE homepage, I have a local copy of the excerpt from IEEE Std. 1619-2007. Micah does so too, as he mentiones below. greetings, jonas ----- Forwarded message from Micah Anderson <micah-sGOZH3hwPm2sTnJN9+BGXg< at >public.gmane.org> ----- Date: Mon, 1 Sep 2008 23:13:05 -0400 From: Micah Anderson <micah-sGOZH3hwPm2sTnJN9+BGXg< at >public.gmane.org> Subject: [pkg-cryptsetup-devel] Bug#494584: efficacy of xts over 1TB To: 494584-61a8vm9lEZVf4u+23C9RwQ< at >public.gmane.org Reply-To: Micah Anderson <micah-sGOZH3hwPm2sTnJN9+BGXg< at >public.gmane.org>, 494584-61a8vm9lEZVf4u+23C9RwQ< at >public.gmane.org According to the IETF NIST submission[0] for the tweakable block cipher xts (and I paraphrase here, as the document prohibits direct quotation): the proof yields strong security guarantees as l Jonas Meurer 2008-09-02T12:28:33 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2801 Hi, I am planning to use LUKS with openSUSE 11.0 on a notebook (x86_64) with a fingerprint scanner (aes2501). I will proceed along the `encrypted root file system HOWTO' procedure given in http://en.opensuse.org/Encrypted_Root_File_System_with_SUSE_HOWTO I wonder if the identification process for decrypting the file system can be tied to identification with the fingerprint scanner (using, as planned, for example fprint; http://reactivated.net/fprint/wiki/Main_Page). Thanks for any help or experience report. Regards Bernd Bernd Speiser 2008-08-30T13:04:52 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2799 Hi, The header selfcorrupted again a couple of hours again. It said something it didn't have a partion with that password even if I tried ten times and connected other units so it was named sdb and sdc. Nothing worked. Since it's an external harddrive I opened the enclosure and connected it to the Secondary Master and then it worked. I don't know if it's useful, but when it's not recognized as a LUKS-unit, just connect it to another port. It helped me before and helped me again. I haven't subscribed to the mailinglist. If you want an answer, replay to my email. Kind regards Martin Martin Nihlberg 2008-08-10T23:36:53 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2798 spammed 2008-08-08T10:20:07 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2797 spammed 2008-08-08T09:48:26 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2795 Hello! I've used cryptsetup for a while now and started looking at the code. I thought I'd share some additional error checks. I noticed that when a new master key is generated (when doing luksFormat) a call to getRandom did not check the return value. If getRandom were to fail, the master key would not be set (or set to the uninitialized memory previously allocated), but aside from an error message the program would continue as if nothing happened. The patch merely checks the return value of getRandom and fails if getRandom fails. I also removed an unused variable in the getRandom function itself. In that function there were two variables r, one shadowing the other, so I removed one which wasn't used. The change is fairly simple, it compiles and "make test" in the luks sub-directory succeeds as far as I can tell, but I haven't tested it further. Regards, Erik Edin Index: lib/setup.c =================================================================== --- lib/setup.c(revision 58) +++ lib/setup Erik Edin 2008-08-07T22:32:01 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2790 Due to a combination of hardware failure, ignorance, and stupidity I have managed to really make a mess of a 7 drive mdadm (raid5) -> lvm -> luks -> ext3 setup. So here is the basic setup: 1. sudo badblocks -c 16384 -s -w -t random -v /dev/sd (on all 7 drives) 2. sudo mdadm --create --verbose /dev/md0 --level=5 --chunk=256 --force --raid-devices=7 /dev/sd[a,b,c,d,e,f,g] 3. pvcreate /dev/md0 4. vgcreate lg /dev/md0 -s 256M 5. lvcreate -l22356 -nlv lg 6. cryptsetup --verify-passphrase --verbose --hash=sha256 --cipher=aes-cbc-essiv:sha256 --key-size=128 luksFormat /dev/lg/lv 7. cryptsetup luksOpen /dev/lg/lv encrypted 8. mkfs.ext3 -j -m 3 -O dir_index,filetype,sparse_super,large_file /dev/mapper/encrypted So long story short, the hardrives were swapped around and one point which cause blkid.tab to go crazy and remap the drives to different letters. All but one of the mdadm superblocks were erased, but I believe the array was clean before this happened. By using basically the same command first us Clayton Shepard 2008-08-07T08:37:51 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2788 I haven't been able to post my question about cryptsetup yet. Test ... Mick Reed 2008-08-02T02:18:26 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2787 This may be a feature request, or just a call for some bash scripting help: I would like to add a (piped, gpg'ed) key to a luks partition that was originally formatted with a piped key from gpg: Create the container # gpg --decrypt --quiet 2>>/dev/null first_key.gpg | cryptsetup \ luksFormat /dev/partition So gpg will ask for my passphrase for my (usb random) key, and then pipe the decrypted output to cryptsetup, creating the container. Now comes the question: how to pipe in the original key and a new piped key at the same time, for the luksAddKey action. I have tried unsuccessfully to use the --key-file=- option and some bash constructs like (subshells) and {code blocks} along with pipes. The best I have been able to do is get the new key in, but with a <cr> added or some other mangling. That doesn't work, when later trying to luksOpen the container with the new key. To clarify further, I don't want to use an intermediate or temporary cleartext key, or UUencode either of the random gpg Mick Reed 2008-07-30T21:40:01 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2786 This may be a feature request, or just a call for some bash scripting help: I would like to add a (piped, gpg'ed) key to a luks partition that was originally formatted with a piped key from gpg: Create the container # gpg --decrypt --quiet 2>>/dev/null first_key.gpg | cryptsetup \ luksFormat /dev/partition So gpg will ask for my passphrase for my (usb random) key, and then pipe the decrypted output to cryptsetup, creating the container. Now comes the question: how to pipe in the original key and a new piped key at the same time, for the luksAddKey action. I have tried unsuccessfully to use the --key-file=- option and some bash constructs like (subshells) and {code blocks} along with pipes. The best I have been able to do is get the new key in, but with a <cr> added or some other mangling. That doesn't work, when later trying to luksOpen the container with the new key. To clarify further, I don't want to use an intermediate or temporary cleartext key, or UUencode either of the random gpg Mick Reed 2008-07-30T18:05:02 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2785 Hi folks, Debian and Ubuntu installers include a "standard" way of building a fully-encrypted machine on a LUKS-encrypted LVM. On top of this, I have written a more or less "universal" keyscript allowing the machine's LVM key to reside as a file on a removable device (i.e. USB key or SD-card) so this removable device will be the "key" for using the machine. That's quite convenient. The removable device partition on which the keyfile resides can be FAT, ext2/3, or itself a LUKS-encrypted partition in which case the bootkeyscript will prompt for its passphrase for unlocking it and getting the key to the machine's main encrypted LVM. This allows for "two form factor authentication". My script is rather automagic and doesn't need much more than being installed somewhere on the machine (typically /usr/local/sbin) and mentioned in /etc/crypttab before the initramfs is regenerated. It doesn't need no change to the standard Debian or Ubuntu encrypted LVM setup or initramfs (besides mentioning the need Swâmi Petaramesh 2008-07-22T06:04:58 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.device-mapper.dm-crypt