gmane.linux.kernel.device-mapper.dm-crypt

Re: partition table problem

2008-10-02T16:55:40

Well after a week i still haven't found anything like what happens to me, i'd like to know if there is a chance to recover my disk or i just i've to give up and format my partition 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 b3 eb 82 b7 9d > MK iterations: 10 > UUID: f88a5886-99db-44de-b8f1-693297480c66 > > Key Slot 0: ENABLED > Iterations: 104407 > Salt: 7a 27 e1 47 c9 94 9a 31 bd e6 95 4c 68 57 > ff 86 > 1c 2a f8 ff 7b ad 18 ec 49 fe ae e7 f4 c2 > 4f 44 > Key material offset: 8 > AF stripes: 4000 > Key Slot 1: DISABLED > Key Slot 2: DISABLED > Key Slot 3: DISABLED > Key Slot 4: DISABLED > Key Slot 5: DISABLED > Key Slot 6: DISABLED > Key Slot 7: DISABLED > > i cannot unlock slot 0 and when i open gparted its said that the crypted > partition is format like ext2 and before i made the change on partition > table its said that was format in ext3. > i was googling a lot and i cannot found any similar problem. > Any extra information you need ask me for and i will send to you. > > > >

Re: luksClose: what does it do?

Milan Broz — 2008-09-29T07:55:20

luksClose basically calls device-mapper remove ioctl. When the crypt target is removed, destructor wipes memory with key before the memory is deallocated. See crypt_dtr() call in dm-crypt.c in kernel source. In userspace for luksClose is no key needed - so there is no risk at all. Milan -- mbroz-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org

luksClose: what does it do?

justin — 2008-09-25T15:55:45

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-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

Re: Request for Comments: Pledge fund for multicore support

Antonio De Leon — 2008-09-26T20:37:56

It would be nice to have that in the kernel.

Re: Request for Comments: Pledge fund for multicore support

Mick Reed — 2008-09-26T18:05:10

If the neighborhood of $200 is feasible, I would pledge probably $5 or more. I'm ignorant on the issue whether it is necessary, but I would like to know. Maybe writing it is the way to find out. HTH Mick

Re: Request for Comments: Pledge fund for multicoresupport

Sami Liedes — 2008-09-26T10:48:21

No, not as far as I know. Sami

Re: Request for Comments: Pledge fund for multicore support

Clemens Fruhwirth — 2008-09-26T08:24:08

At Fri, 12 Sep 2008 17:10:11 +0300, Sami Liedes public.gmane.org> wrote: I'm all pro micro-pledge and multicore support (Please don't reply to that statement, I read the discussion of last week and I didn't find it to be convincing at all) The reason behind this is that I looked at the code in the meantime and I have the impression that it shouldn't be that hard to get at parallelization on at least bio request level. If the micropledge idea turns out to be successful (pledge > 200$[1]) I might look at it more closely. Sami, is there a micropledge yet? I haven't found one. -- Fruhwirth Clemens - http://clemens.endorphin.org [1] I'd really like to see the pledge in a stable currency. Dollars are at the moment totally worthless to me as I'm living in EUR land, and this isn't going to be better next week after the massive infussion of fiat currency authorized in the last few days.

Re: security for failed removal of crypt device?

Mathieu SEGAUD — 2008-09-24T16:29:03

Vous m'avez dit récemment : I don't think you want to umount a swap partition, maybe swapoff it ok, it is here, but still you don't want to umount it.

Re: security for failed removal of crypt device?

Milan Broz — 2008-09-23T18:10:06

If you want to remove mapping correctly, you just have to first umount filesystem. Then luksClose cannot fail:-) Anyway, there are possibilities how to force remove crypt mapping, But please do not use it - it is an emergency procedure, not something for initscripts. For the archive, this is really low level device handling: 1) If you really want to force remove secure material from memory, you must remove crypt mapping. Force *dangerous* (== you can easily lost data if there is still mounted fs and running IOs) way is after unsucessfull cryptsetup luksClose run dmsetup remove -f If the device is still open, it will force replace mapped device with error segment (-f == force). This means, that all following IO operation will fail and also it removes crypt mapping and replaces it with mapping to error target (and this wipes encryption key from memory too). 2) More safe way is to use key wipe message for dm-crypt mapped device. You need to suspend device and then send wipe message dmsetup suspend dmsetup message 0 key wipe. Mapping is still prepared, but running IOs should be frozen now, key is wiped. No IO operation can happen till the key is reinstated and device resumed (this mode was intended for safe suspend to ram + preventing coldboot attack searching for encryption key). You can reinstate key later by running dmsetup message 0 key set dmsetup resume ... Also, if device is left open, kernel can have some pages with sensitive data caches, you probably should flush all kernel caches too. Milan -- mbroz-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org

Re: security for failed removal of crypt device?

smallnow — 2008-09-23T17:53:35

> However I would feel not to good about the "rm". Would > it not be better to check the output of "mount"? Ok, I hear you and I'm thinking better safe than sorry. Heres a revision that shuts down on any failure and tries to take care of memory using secure-delete's smem. cd /dev/mapper fuser -km crypt-foo err=0 if ! umount crypt-foo crypt-swap; then err=1 umount -l crypt-foo; fi if ! cryptsetup luksClose crypt-foo; then err=1 rm -f crypt-foo; fi if ! swapoff -a && cryptsetup remove crypt-swap; then err=1 rm -f crypt-swap; fi smem ((err)) && halt - Drew

Re: security for failed removal of crypt device?

Arno Wagner — 2008-09-23T17:20:46

In light of some recent publications, powering off still makes it secure, it may just take a quater hour or so. However I would feel not to good about the "rm". Would it not be better to check the output of "mount"? Arno

partition table problem

2008-09-23T12:36:56

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 b3 eb 82 b7 9d MK iterations: 10 UUID: f88a5886-99db-44de-b8f1-693297480c66 Key Slot 0: ENABLED Iterations: 104407 Salt: 7a 27 e1 47 c9 94 9a 31 bd e6 95 4c 68 57 ff 86 1c 2a f8 ff 7b ad 18 ec 49 fe ae e7 f4 c2 4f 44 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED i cannot unlock slot 0 and when i open gparted its said that the crypted partition is format like ext2 and before i made the change on partition table its said that was format in ext3. i was googling a lot and i cannot found any similar problem. Any extra information you need ask me for and i will send to you.

security for failed removal of crypt device?

Ian Kelling — 2008-09-23T07:37:46

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

Re: Off Disk LUKS Header

Till Maas — 2008-09-18T19:27:51

If a user only knows the passphrase of a luks encrypted device, but does not have root priviledges[1], then key management is still possible. One way to achieve is is for example using a wrapper around cryptsetup to only allow luksOpen and luksClose, e.g. via sudo. The --key-file is used to use a file instead of manually entered text as the "passphrase". The only "simple" solution that comes to my mind for some of this would be to use dmsetup to create a virtual device, where the first X bytes that contain the luks header are mapped to another location, e.g. on a loopback device with a file on a usb stick, and the remaining data mapped to the disk. But I do not know, how you could add gpg to this setup. Also I do not know the right commandline to do this with dmsetup. [1] To be more precise: The user must not have access to the encrypted data and the output of "dmsetup table" and other data sources, e.g. the contents of the memory. Regards, Till

Re: Re: Request for Comments: Pledge fund for multicore support

Arno Wagner — 2008-09-18T16:39:21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Sep 18, 2008 at 04:55:35AM +0200, Jan Reusch wrote: That is where the "competent" comes in. Ordinary programming skills are not enough, an understanding of security is needed. However, quite frankly, the cipher set-up is the kernel memory anyways, and said "competents" can use it to decryopt a LUKS partition. AFAIK, nothing in kernel memory is protected from root. Still a good idea to do, as a non-overwritten key/passphrase can stay in memory a long time after an encrypted partition has been umounted. wuld require a different input mode though. Maybe a file/stdinput that lists a set of PGP/GnuPG protected keyfiles and the associated partitions? Arno - -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno-JoEyUyqlpX17tPAFqOLdPg< at >public.gmane.org GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F - ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI0oQ5eX9rUB4lM48RAt9/AKCWIWS+7NZOt7ihxpBnCOYnFRNonwCaAtfG kNVzK90UmiQGHddqrYE2NPQ= =NRHm -----END PGP SIGNATURE-----

Re: Request for Comments: Pledge fund for multicore support

Michael Gebetsroither — 2008-09-18T03:07:57

Another way would be to put the key material into the kernel keyring API an let dm-crypt use it. Would it be possibel to integrate the keyring api into dm-crypt/cryptsetup? A nice sideeffekt of this would be that, cryptsetup can setup an environment where normal shellscripts operate only on the keyid's. So they don't have to handle raw key-material. cu, michael

Re: Re: Request for Comments: Pledge fund for multicore support

Jan Reusch — 2008-09-18T02:55:35

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi there Arno Wagner schrieb: a well at this point you have to be very careful. one reason christophe initially switched vom a scripted cryptsetup to a c implementation was that he could reliably erase the memory region the password was stored in. some time ago there was a request to implement this behavior into cryptsetup, it shouldn't be to hard to split the parameters and place the while() into the right area. Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0cMnBpRI6A8tC0MRAg1oAJ0QxgHGnBBHaQGHpgDZVjN+35jqdgCfe2YB dRMsGVi+4wtJPl0AdHBugTE= =mwU8 -----END PGP SIGNATURE-----

Re: Re: Request for Comments: Pledge fund for multicore support

Arno Wagner — 2008-09-18T01:08:32

I agree. In addition this can be done by anybody competent, as it does not need insights into the LUKS implementation. While I have not looked into teh 1TB issue, using the same masterkey, you would probably need to add all disk sizes together in order to determine whether this is vulnerable. That should be fine, as then the devices are effectively independent. There might be some issue of on-disk structure from the RAID, but that should still not be a problem, especially with independent keys. The pasphrase only protects the keys, and the key material is not really a lot (i.e. << 1TB ;-), so I do not see any problem with usiong the same passphrase for multiple keys. Arno

Re: Request for Comments: Pledge fund for multicore support

Michael Gebetsroither — 2008-09-18T00:16:43

Except those lovely ssd's from which you get about 170-200MB/s from one disk. No, not that they bought a slow PC. A new quad-core is quite a bit slower in single threaded performance as a high-end dual-core. Even if the quad-core has much greater multi-threaded performance, single threaded workloads are not their friends. Intel just released a 6x core and the 8 cores are on the way to the mainstream. Thats what i meant with single threaded performance is about to drop quite noticeable in the next years. Just take the sun T1/T2 as example. Even if they have hw crypto engines for every core, you have to feed them from multiple threads to saturate a Gbit link. For really large files, e.g vides, it's possibel to make a few partitions with dm-crypt and combine them into a raid0 with large chunk size (to keep the seeking low). This setup is quite usable for streaming workloads but is unusable for anything other. Not a big issue yet, ack. I just wanted to note that the situation will get a lot worse in the next years. cu, michael

Off Disk LUKS Header

Clayton Shepard — 2008-09-17T23:10:13

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, however, don't see any easy way to create this system right now. Is there a way to use the luksFormat to output the header to a file or something? (Is this what the --key-file is for? It kind of seems like this uses a pre-existing key, and does not create a new header...) In other words I would like to call luksFormat, but rather than prepend the header to the beginnning of the device it puts it somewhere user specified (preferably piped through gpg). Then I can reopen the device via something like "gpg --decrypt ./root-key.gpg 2>/dev/null | cryptsetup luksOpen /dev/sdx7 root" (as mentioned on the FAQ) and entering a password (while still up to 8 passwords work). Should I just create a LUKS device like I normally would then manually wipe the header (before backing it up)? That seems tedious, insecure, and unnecessary, especially if piping a luksHeader to cryptsetup will already allow it to open a device. I apologize if this is a newbish question, I just didn't find any tutorials on how to do it right off... Thanks, -Clay http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2005-12/msg00042.html http://clemens.endorphin.org/weblog/archives/2006-03.shtml#e2006-03-30T19_26_01.txt http://osdir.com/ml/kernel.device-mapper.dm-crypt/2006-05/msg00033.html

Re: Re: Request for Comments: Pledge fund for multicore support

Clayton Shepard — 2008-09-17T21:29:36

It sounds like it may be more effective, and much less code, to write a well scripted front end that manages and automates the creation and opening of multiple LUKS devices at once. IE create 12 LUKS devices with one the same passphrase with one command, and then open all 12 with one command. Although I personally don't really use the pasphrase management features - I guess a similar command to add and revoke passphrases would also be needed. I am not a cryptology expert, so I do not know what impact having all 12 of these with the same/different masterkey would have on security. It seems like all of them having the same key couldn't be any worse than the > 1TB problem it is already faced with. Would 12 different masterkeys with the same passphrase present any security problems? -Clay On Wed, Sep 17, 2008 at 11:20 AM, Mick Reed public.gmane.org> wrote: