Selfcorrupted header again, but...

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]

Index: luks/keymanage.c
===================================================================
--- luks/keymanage.c	(revision 58)
+++ luks/keymanage.c	(working copy)
@@ -83,7 +83,7 @@
 		return -EINVAL; 
 	}

-	if(read_blockwise(devfd, hdr, sizeof(struct luks_phdr)) < sizeof(struct luks_phdr)) {
+	if(read_blockwise(devfd, hdr, sizeof(struct luks_phdr)) < (ssize_t)sizeof(struct luks_phdr)) {
 		r = -EIO;
 	} else if(memcmp(hdr->magic, luksMagic, LUKS_MAGIC_L)) { /* Check magic */
 		set_error(_("%s is not a LUKS partition\n"), device);
@@ -138,7 +138,7 @@
 		convHdr.keyblock[i].stripes            = htonl(hdr->keyblock[i].stripes);
 	}

-	r = write_blockwise(devfd, &convHdr, sizeof(struct luks_phdr)) < sizeof(struct luks_phdr) ? -EIO : 0;
+	r = write_blockwise(devfd, &convHdr, sizeof(struct luks_phdr)) < (ssize_t)sizeof(struct
luks_phdr) ? -EIO : 0;

 	close(devfd);
 	return r;

Index: luks/keymanage.c
===================================================================
--- luks/keymanage.c	(revision 58)
+++ luks/keymanage.c	(working copy)
@@ -83,7 +83,7 @@
 		return -EINVAL; 
 	}

-	if(read_blockwise(devfd, hdr, sizeof(struct luks_phdr)) < sizeof(struct luks_phdr)) {
+	if(read_blockwise(devfd, hdr, sizeof(struct luks_phdr)) < (ssize_t)sizeof(struct luks_phdr)) {
 		r = -EIO;
 	} else if(memcmp(hdr->magic, luksMagic, LUKS_MAGIC_L)) { /* Check magic */
 		set_error(_("%s is not a LUKS partition\n"), device);
@@ -138,7 +138,7 @@
 		convHdr.keyblock[i].stripes            = htonl(hdr->keyblock[i].stripes);
 	}

-	r = write_blockwise(devfd, &convHdr, sizeof(struct luks_phdr)) < sizeof(struct luks_phdr) ? -EIO : 0;
+	r = write_blockwise(devfd, &convHdr, sizeof(struct luks_phdr)) < (ssize_t)sizeof(struct
luks_phdr) ? -EIO : 0;

 	close(devfd);
 	return r;

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

Index: src/cryptsetup.c
===================================================================
--- src/cryptsetup.c	(revision 58)
+++ src/cryptsetup.c	(working copy)
@@ -66,7 +66,7 @@
 	{ "luksAddKey",	action_luksAddKey, 0, 1, N_("<device> [<new key file>]"), N_("add key to LUKS
device") },
 	{ "luksRemoveKey", action_luksRemoveKey, 0, 1, N_("<device> [<key file>]"), N_("removes supplied
key or key file from LUKS device") },
 	{ "luksKillSlot",  action_luksKillSlot, 0, 2, N_("<device> <key slot>"), N_("wipes key with number
<key slot> from LUKS device") },
-	{ "luksUUID",	action_luksUUID, 0, 1, N_("<device>"), N_("print UUID of LUKS device") },
+	{ "luksUUID",	action_luksUUID, 0, 1, N_("<device> [<new UUID>]"), N_("print or change UUID of LUKS
device") },
 	{ "isLuks",	action_isLuks, 0, 1, N_("<device>"), N_("tests <device> for LUKS partition header") },
 	{ "luksClose",	action_remove, 0, 1, N_("<name>"), N_("remove LUKS mapping") },
 	{ "luksDump",	action_luksDump, 0, 1, N_("<device>"), N_("dump LUKS partition information") },
@@ -370,6 +370,7 @@
 	struct crypt_options options = {
 		.device = action_argv[0],
 		.icb = &cmd_icb,
+		.new_uuid = action_argc>1?action_argv[1]:NULL,
 	};
 	int r;

Index: lib/libcryptsetup.h
===================================================================
--- lib/libcryptsetup.h	(revision 58)
+++ lib/libcryptsetup.h	(working copy)
@@ -22,6 +22,8 @@
 	const char	*name;
 	const char	*device;

+	const char      *new_uuid;
+
 	const char	*cipher;
 	const char	*hash;

Index: lib/setup.c
===================================================================
--- lib/setup.c	(revision 58)
+++ lib/setup.c	(working copy)
@@ -10,6 +10,7 @@
 #include <errno.h>
 #include <signal.h>
 #include <assert.h>
+#include <uuid/uuid.h>

 #include "libcryptsetup.h"
 #include "internal.h"
@@ -767,10 +768,23 @@
 {
 	struct luks_phdr hdr;
 	int r;
+	uuid_t test_uuid;

 	r = LUKS_read_phdr(options->device,&hdr);
 	if(r < 0) return r;

+	if (options->new_uuid) {
+
+     		if (!uuid_parse(options->new_uuid,test_uuid)) {
+			uuid_unparse(test_uuid, hdr.uuid);
+			r = LUKS_write_phdr(options->device,&hdr);
+			if(r < 0) return r;
+		}
+		else {
+			options->icb->log(CRYPT_LOG_ERROR,"Invalid format, UUID not changed\n");
+			return -EINVAL;
+		}
+	}
 	options->icb->log(CRYPT_LOG_NORMAL,hdr.uuid);
 	options->icb->log(CRYPT_LOG_NORMAL,"\n");
 	return 0;

Index: src/cryptsetup.c
===================================================================
--- src/cryptsetup.c	(revision 58)
+++ src/cryptsetup.c	(working copy)
@@ -66,7 +66,7 @@
 	{ "luksAddKey",	action_luksAddKey, 0, 1, N_("<device> [<new key file>]"), N_("add key to LUKS
device") },
 	{ "luksRemoveKey", action_luksRemoveKey, 0, 1, N_("<device> [<key file>]"), N_("removes supplied
key or key file from LUKS device") },
 	{ "luksKillSlot",  action_luksKillSlot, 0, 2, N_("<device> <key slot>"), N_("wipes key with number
<key slot> from LUKS device") },
-	{ "luksUUID",	action_luksUUID, 0, 1, N_("<device>"), N_("print UUID of LUKS device") },
+	{ "luksUUID",	action_luksUUID, 0, 1, N_("<device> [<new UUID>]"), N_("print or change UUID of LUKS
device") },
 	{ "isLuks",	action_isLuks, 0, 1, N_("<device>"), N_("tests <device> for LUKS partition header") },
 	{ "luksClose",	action_remove, 0, 1, N_("<name>"), N_("remove LUKS mapping") },
 	{ "luksDump",	action_luksDump, 0, 1, N_("<device>"), N_("dump LUKS partition information") },
@@ -370,6 +370,7 @@
 	struct crypt_options options = {
 		.device = action_argv[0],
 		.icb = &cmd_icb,
+		.new_uuid = action_argc>1?action_argv[1]:NULL,
 	};
 	int r;

Index: lib/libcryptsetup.h
===================================================================
--- lib/libcryptsetup.h	(revision 58)
+++ lib/libcryptsetup.h	(working copy)
@@ -22,6 +22,8 @@
 	const char	*name;
 	const char	*device;

+	const char      *new_uuid;
+
 	const char	*cipher;
 	const char	*hash;

Index: lib/setup.c
===================================================================
--- lib/setup.c	(revision 58)
+++ lib/setup.c	(working copy)
@@ -10,6 +10,7 @@
 #include <errno.h>
 #include <signal.h>
 #include <assert.h>
+#include <uuid/uuid.h>

 #include "libcryptsetup.h"
 #include "internal.h"
@@ -767,10 +768,23 @@
 {
 	struct luks_phdr hdr;
 	int r;
+	uuid_t test_uuid;

 	r = LUKS_read_phdr(options->device,&hdr);
 	if(r < 0) return r;

+	if (options->new_uuid) {
+
+     		if (!uuid_parse(options->new_uuid,test_uuid)) {
+			uuid_unparse(test_uuid, hdr.uuid);
+			r = LUKS_write_phdr(options->device,&hdr);
+			if(r < 0) return r;
+		}
+		else {
+			options->icb->log(CRYPT_LOG_ERROR,"Invalid format, UUID not changed\n");
+			return -EINVAL;
+		}
+	}
 	options->icb->log(CRYPT_LOG_NORMAL,hdr.uuid);
 	options->icb->log(CRYPT_LOG_NORMAL,"\n");
 	return 0;

[PATCH] Improve error checks when generating LUKS master key

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.c	(arbetskopia)
@@ -390,7 +390,7 @@
 	}

 	mk = LUKS_generate_masterkey(options->key_size);
-	if(NULL == mk) return -ENOMEM; 
+	if(NULL == mk) return -ENOMEM; // FIXME This may be misleading, since we don't know what went wrong

 #ifdef LUKS_DEBUG
 #define printoffset(entry) logger(options, CRYPT_LOG_ERROR, ("offset of " #entry " = %d\n", (char
*)(&header.entry)-(char *)(&header))
Index: luks/random.c
===================================================================
--- luks/random.c	(revision 58)
+++ luks/random.c	(arbetskopia)
@@ -23,8 +23,6 @@
    closeRandom */
 int getRandom(char *buf, size_t len)
 {
-    int r = 0;
-
     if(openRandom() == -1) {
 	perror("getRandom:");
 	return -EINVAL;
@@ -37,7 +35,7 @@
 	}
 	len-= r; buf += r;
     }
-    return r;
+    return 0;
 }

 void closeRandom() {
Index: luks/keymanage.c
===================================================================
--- luks/keymanage.c	(revision 58)
+++ luks/keymanage.c	(arbetskopia)
@@ -50,6 +50,7 @@
 struct luks_masterkey *LUKS_alloc_masterkey(int keylength)
 { 
 	struct luks_masterkey *mk=malloc(sizeof(*mk) + keylength);
+	if(NULL == mk) return NULL;
 	mk->keyLength=keylength;
 	return mk;
 }
@@ -66,7 +67,13 @@
 struct luks_masterkey *LUKS_generate_masterkey(int keylength)
 {
 	struct luks_masterkey *mk=LUKS_alloc_masterkey(keylength);
-	getRandom(mk->key,keylength);
+	if(NULL == mk) return NULL;
+
+	int r = getRandom(mk->key,keylength);
+	if(r < 0) {
+		LUKS_dealloc_masterkey(mk);
+		return NULL;
+	}
 	return mk;
 }

Index: lib/setup.c
===================================================================
--- lib/setup.c	(revision 58)
+++ lib/setup.c	(arbetskopia)
@@ -390,7 +390,7 @@
 	}

 	mk = LUKS_generate_masterkey(options->key_size);
-	if(NULL == mk) return -ENOMEM; 
+	if(NULL == mk) return -ENOMEM; // FIXME This may be misleading, since we don't know what went wrong

 #ifdef LUKS_DEBUG
 #define printoffset(entry) logger(options, CRYPT_LOG_ERROR, ("offset of " #entry " = %d\n", (char
*)(&header.entry)-(char *)(&header))
Index: luks/random.c
===================================================================
--- luks/random.c	(revision 58)
+++ luks/random.c	(arbetskopia)
@@ -23,8 +23,6 @@
    closeRandom */
 int getRandom(char *buf, size_t len)
 {
-    int r = 0;
-
     if(openRandom() == -1) {
 	perror("getRandom:");
 	return -EINVAL;
@@ -37,7 +35,7 @@
 	}
 	len-= r; buf += r;
     }
-    return r;
+    return 0;
 }

 void closeRandom() {
Index: luks/keymanage.c
===================================================================
--- luks/keymanage.c	(revision 58)
+++ luks/keymanage.c	(arbetskopia)
@@ -50,6 +50,7 @@
 struct luks_masterkey *LUKS_alloc_masterkey(int keylength)
 { 
 	struct luks_masterkey *mk=malloc(sizeof(*mk) + keylength);
+	if(NULL == mk) return NULL;
 	mk->keyLength=keylength;
 	return mk;
 }
@@ -66,7 +67,13 @@
 struct luks_masterkey *LUKS_generate_masterkey(int keylength)
 {
 	struct luks_masterkey *mk=LUKS_alloc_masterkey(keylength);
-	getRandom(mk->key,keylength);
+	if(NULL == mk) return NULL;
+
+	int r = getRandom(mk->key,keylength);
+	if(r < 0) {
+		LUKS_dealloc_masterkey(mk);
+		return NULL;
+	}
 	return mk;
 }

Massive Failure

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 used
to create the array mdadm detected that it was already a raid array and
recreated it - unfortunately it thought that the last drive (sdh at this
time) was dirty, and thus began rebuilding it.  Unfortunately commands 3-7
were also reissued, which initially made me believe that the luks header was
destroyed (according to this thread:
http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2005-12/msg00045.html).
After some time with dd and a hex editor I have found three luks headers on
the drives - two of which are the new header; however it is my hope that the
other one is the original luks header.

I now believe that mdadm did not correctly recreate the raid array,
primarily because that luks header was not wiped out and the array was
created with the drives in a different order.    I do not believe that the
drive that was being rebuilt ever completed (this may be useful for
rebuilding the raid array in the correct order?).

At this point since there are so many ways that I could be SOL, I think the
first step is just for me to verify that the luks header I recovered is the
correct one.  Anyone have any advice on how to do this?  I already dd'd the
first 4mb of each drive in to files, but I am not really sure how to
proceed.  Will I have to trick cryptsetup in to thinking its a device?  Is
there a way to simply decrypt all the data on these little chunks?  I will
probably have a problem with data alignment due to the cryptsetup being
applied after mdadm and lvm, both accross the chunks and on the individual
chunks...  is there anyway to fix that?

Are there any tools similar to R-Studio for linux?

If this is in fact the correct key then I think that I may still be able to
recover most of my data, as I do not believe much other than the various
headers have been corrupted...

Thanks for your help,

-Clay

Piping in keys

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:
> PS: I doubt that it's possible to pipe both the current and a new key to
> cryptsetup luksAddKey at the same time. But why not use a temporary
> passphrase to add the key, and remove the keySlot with the passphrase
> afterwards. That requires passphrase input at least, but it avoids using
> temporary files. On the other hand it should be save to use tempfiles if
> you wipe/shred them afterwards.

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.  That seems less secure to me.  Isn't a USB 
key/encrypted 2-factor security?  Thanks again for any help!

Cheers,
Mick

Please pardon this test

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

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

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 keys.  I also don't want to take 
the key apart and write it to a temporary file.

If we can't find a way to do this, I will be happy to help with a patch.  I am 
not a good enough coder to solve this on my own, yet.  I do think there is a 
need for this, please offer any suggestions.  Thanks!

Mick Reed

Piping two gpg'ed keys to cryptsetup luksAddKey

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 keys.  I also don't want to take 
the key apart and write it to a temporary file.

If we can't find a way to do this, I will be happy to help with a patch.  I am 
not a good enough coder to solve this on my own, yet.  I do think there is a 
need for this, please offer any suggestions.  Thanks!

Mick Reed

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

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 needed kernel modules for accessing the 
removable device in /etc/initramfs-tools/modules and optionally adding 2 
2-lines scripts in /etc/initramfs-tools/hooks for including a couple optional 
binaries in the initramfs.)

The partition on which the keyfile resides can be mentioned in /etc/crypttab 
either by its device name (sdb1) or LABEL or fs UUID (for unencryted fs), or 
LUKS volume UUID (for encrypted fs), allowing it to work on machines on which 
the device ID where the key device is inserted may change from one boot to 
another.

My keyscript can be downloaded from : 
http://petaramesh.org/public/arc/projects/cryptsetup/bootkeyscript
And its GPG signature from : 
http://petaramesh.org/public/arc/projects/cryptsetup/bootkeyscript.asc

A detailed article is available at : 
http://petaramesh.org/post/2007/11/29/Une-cle-de-contact-pour-votre-portable-chiffre

It's in French, but has a shorter English summary at end.

This script has been extensively tested and is daily used with Ubuntu Gutsy 
and Hardy on several laptops using either USB sticks or SD cards as key 
devices. It works plain good.

That's GPL and I would love this script to become part of the 
official "cryptsetup" package for Debian / Ubuntu.

Please Cc: me on answers, as I'm not susbscribed to the dm-crypt mailing-list.

Best regards.

--

-- 
Swâmi Petaramesh <swami@...> http://petaramesh.org PGP 9076E32E

Il est souvent trop tôt pour savoir s'il n'est pas
trop tard.
	-- Pierre Dac

Where is the newest source for cryptsetup?

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