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

Re: Massive Failure

Clayton Shepard — 2008-08-19T03:49:53

Any ideas on how to check to see if I actually have the correct header? On Thu, Aug 7, 2008 at 3:37 AM, Clayton Shepard public.gmane.org> wrote:

Selfcorrupted header again, but...

Martin Nihlberg — 2008-08-10T23:36:53

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

Latent bug [patch]

spammed — 2008-08-08T10:20:07

Feature request: Changing the UUID of a LUKS device [patch]

spammed — 2008-08-08T09:48:26

Re: Re: A12-140 Piping two gpg'ed keys to cryptsetup luksAddKey

Mick Reed — 2008-08-07T23:51:59

Yes, This works for me as well, but when I change <(cat key1) to <(gpg --decrypt --quiet /media/disk/key1.gpg) it no longer works. I tried some quoting there, but no luck yet. My experience is that it works. At least I have not had any problems with my 256 bit keys and several different ones at that. I have made at least 6 containers with different keys, and they could be luksOpened.

[PATCH] Improve error checks when generating LUKS master key

Erik Edin — 2008-08-07T22:32:01

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

Re: Re: A12-140 Piping two gpg'ed keys to cryptsetup luksAddKey

Pasi Kärkkäinen — 2008-08-07T11:38:10

Yep, I noticed this with RHEL 5.1 / CentOS 5.1 .. cryptsetup only used the first line from the file. Dunno if it is fixed in EL 5.2 or in upstream cryptsetup..

Re: A12-140 Piping two gpg'ed keys to cryptsetup luksAddKey

Till Maas — 2008-08-07T10:10:03

This works for me with bash: # cryptsetup luksFormat /dev/loop0 <(cat key1) # cryptsetup --key-file <(cat key1) luksAddKey /dev/loop0 <(cat key2) # cryptsetup --key-file <(cat key2) luksOpen /dev/loop0 foo Btw. piping keyfiles to cryptsetup without using --key-file may be a bad idea. Iirc at least older versions of cryptsetup did not use the full keyfile for encryption, e.g. when it contained newline characters. Regards, Till

Re: Massive Failure

Clayton Shepard — 2008-08-07T09:02:19

Well its not exactly a "header file" I just dumped the first 4mb of each drive with dd. Using a hex-editor with search capabalites I was able to find the luks magic ('L','U','K','S',xBA,xBE) on the same spot on three of the dumps. All of them were clearly luks headers and two of them corresponded exactly to running luksDump on the new /dev/lg/lv (ie the salt, keys, etc all matched). Due to the MDADM and LVM headers preceding the luksHeader I doubt that a straight dump would work. It is, however, fairly easy to extract all of the same info straight from the hex editor. Would there be any point to running a luksDump, or are you just trying to get the keys and such?

Re: Massive Failure

Roscoe — 2008-08-07T08:50:24

Can you use losetup on the header file then cryptsetup luksDump /dev/loopX? On Thu, Aug 7, 2008 at 6:07 PM, Clayton Shepard public.gmane.org> wrote:

Massive Failure

Clayton Shepard — 2008-08-07T08:37:51

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

Piping in keys

Mick Reed — 2008-08-03T04:07:32

Thanks to all who corrected me on my test post. I made a few mistakes there - 'nuff said. On Saturday 02 August 2008, Jonas wrote: That is a good point. Any intermediate/temporary passphrase doesn't need to be written to disk. It can be left in a variable and later destroyed. That isn't the problem I have though: I want to have an extremely secure partition/container. I want the only keys to be random binary and stored on USB keys, encrypted too. When I _create_ the container, lets say that I use my personal USB key, which I carry always. Now, I want to add another similar key. I will need to get my USB key into luksAdd, and then perhaps type in an intermediate/temporary key as you suggest. Well, I've tried it, as I said before, but I cannot get it to work. I could use a suggestion here on how it can be done. If it is possible, then I can work out the rest myself. Otherwise, I will have to start reading the source. I see no need to format the container using a text key or keyfile.

Please pardon this test

Mick Reed — 2008-08-02T02:18:26

I haven't been able to post my question about cryptsetup yet. Test ...

A12-140 Piping two gpg'ed keys to cryptsetup luksAddKey

Mick Reed — 2008-07-30T21:40:01

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 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

Piping two gpg'ed keys to cryptsetup luksAddKey

Mick Reed — 2008-07-30T18:05:02

"Universal" keyscript for LVM encrypted systems with key on removable device

Swâmi Petaramesh — 2008-07-22T06:04:58

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

Re: Where is the newest source for cryptsetup?

Till Maas — 2008-07-19T09:21:08

This is the correct URL: http://luks.endorphin.org/source/ Regards, Till

Where is the newest source for cryptsetup?

spammed — 2008-07-18T21:04:20

Hello to all, Where can I find the newest source for cryptsetup? The announcement for 1.0.6 on 11 March had a link: http://luks.endorphin.org/sources ...but it gives me a 404. Thank you in advance. Best Regards, Jacob Nielsen

Re: Any way to integrate Microsoft PKI into dm-crypt?

Arno Wagner — 2008-07-17T01:07:32

The only way to do that is with LUKS and setting more than one key. You can then call one of them the "organizational" key and store it separately. With dm-cryot there is only one key and this approach is not possible. Indeed. Arno

Re: Any way to integrate Microsoft PKI into dm-crypt?

Thomas Cameron (Red Hat — 2008-07-16T23:09:26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 wof wrote: I probably did not phrase it well, sorry. That I understand, but the customer is asking about doing something like what Microsoft does when the key is lost, that an admin can still access the encrypted information. I think the short answer here is that we don't really want to mingle the Microsoft PKI stuff with LUKS keys. The solution is simply to set up the customer's workstations with encrypted slices with a user key and something like a helpdesk key. No need to get PKI involved. Thanks for your response. - -- Thomas Cameron, RHCE, RHCX, CNE, MCSE, MCT Solutions Architect Team Lead, Central Region 512-241-0774 office / 512-585-5631 cell / 512-857-1345 fax -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIfn+lmzle50YHwaARAtifAJ9MKDc/QnUxr8YtwwSv/CfhHE/mdACgvysB CxryaWSht7jCNDsrqhoWams= =8gTv -----END PGP SIGNATURE-----

Re: Any way to integrate Microsoft PKI into dm-crypt?

wof — 2008-07-16T22:59:59

I'm not sure if I get your question. There is no native support from Microsoft's PKI to dmcrypt and the other way. If you need a backup key for your disk encryption, you can backup the key. This is merely an organisational process. dm-crypt is a device encryption, EFS is based on files and directories. This is a different. If you would like to have features like EFS in Linux mayby eCryptfs (http://ecryptfs.sourceforge.net/) is the right thing for you. dm-crypt doesn't support x509, but you can use the certificates to encrypt the used key. Not direct, but you can use e.g. openssl to encrypt/decrypt a key with a x509 certificate and use this key for luks or native dm-crpyt. wof