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/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 udev rules in the first case!) But we can use device mapper and remap open device, similar way how "dmsetup -f remove works" instead of waiting. See attached patch. Please could we submit it upstream? Better ideas welcome:) Patch description: - It adds force flag to device-mapper backend remove call. If force flag is specified, temporary mapped device is replaced by read only error segment (all IO will return -EIO now). It basically finish ongoing IO transaction and all following IOs should finish immediately with error. So the udev scanning should be finished very quickly now :-) Force flag must not be set for real mapping, if real (not temporary) mapped device is still open, there can be mounted fs or so - so it is correct to fail here. - After replacing with error device, It tries to remove temporary-device completely - RETRY_COUNT times. In the worst case it fails (someone still blocking temporary device), but underlying crypt device is now not used in mapping, so we can continue safely. (IOW: in the worst case it keeps temporary error mapped device in system. If this happens, the problem is for sure in some system cfg, nobody should try to open temporary cryptsetup devices. But it is not blocking cryptsetup from operation now. It is workaround till udev rules are fixed in all distros to not touch temporary cryptsetup devices...) - It removes udev calls completely. Not needed now. - It uses dm_task_update_nodes() instead of dm library reinitialization workaround. Patch is based on upstream SVN + my previous zero fd patch in ctrl+c handler. Milan -- mbroz-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org p.s. any feedback appreciated, I would like to submit this patch to Fedora cryptsetup ASAP... Use remapping to error target instead of calling udevsettle. --- lib/internal.h | 2 lib/libdevmapper.c | 143 ++++++++++++++++++++++++++++++++------------------- lib/setup.c | 2 luks/keyencryption.c | 26 ++++----- 4 files changed, 104 insertions(+), 69 deletions(-) Index: cryptsetup.my/lib/libdevmapper.c =================================================================== --- cryptsetup.my.orig/lib/libdevmapper.c2008-09-04 14:17:33.000000000 +0200 +++ cryptsetup.my/lib/libdevmapper.c2008-09-04 14:21:36.000000000 +0200 < at >< at > -17,20 +17,7 < at >< at > #define DEVICE_DIR"/dev" #defineCRYPT_TARGET"crypt" - -#define UDEVSETTLE"/sbin/udevsettle" -#define UDEVADM"/sbin/udevadm" -#define UDEVADM_ARGS"settle --timeout=30" - -static void run_udevsettle(void) -{ -#ifndef SKIP_UDEVSETTLE -if (!access(UDEVADM, X_OK)) -system(UDEVADM " " UDEVADM_ARGS); -else if (!access(UDEVSETTLE, X_OK)) -system(UDEVSETTLE); -#endif -} +#define RETRY_COUNT5 static void set_dm_error(int level, const char *file, int line, const char *f, ...) < at >< at > -57,16 +44,6 < at >< at > static void dm_exit(void) dm_lib_release(); } -static void flush_dm_workqueue(void) -{ -/* - * Unfortunately this is the only way to trigger libdevmapper's - * update_nodes function - */ -dm_exit(); -dm_init(); -} - static char *__lookup_dev(char *path, dev_t dev) { struct dirent *entry; < at >< at > -159,6 +136,89 < at >< at > out: return params; } +/* DM helpers */ +static int _dm_simple(int task, const char *name) +{ +int r = 0; +struct dm_task *dmt; + +if (!(dmt = dm_task_create(task))) +return 0; + +if (!dm_task_set_name(dmt, name)) +goto out; + +r = dm_task_run(dmt); + + out: +dm_task_destroy(dmt); +return r; +} + +static int _error_device(struct crypt_options *options) +{ +struct dm_task *dmt; +int r = 0; + +if (!(dmt = dm_task_create(DM_DEVICE_RELOAD))) +return 0; + +if (!dm_task_set_name(dmt, options->name)) +goto error; + +if (!dm_task_add_target(dmt, UINT64_C(0), options->size, "error", "")) +goto error; + +if (!dm_task_set_ro(dmt)) +goto error; + +if (!dm_task_no_open_count(dmt)) +goto error; + +if (!dm_task_run(dmt)) +goto error; + +if (!_dm_simple(DM_DEVICE_RESUME, options->name)) { +_dm_simple(DM_DEVICE_CLEAR, options->name); +goto error; +} + +r = 1; + +error: +dm_task_destroy(dmt); +return r; +} + +static int _dm_remove(struct crypt_options *options, int force) +{ +int r = -EINVAL; +int retries = force ? RETRY_COUNT : 1; + +/* If force flag is set, replace device with error, read-only target. + * it should stop processes from reading it and also removed underlying + * device from mapping, so it is usable again. + * Force flag should be used only for temporary devices, which are + * intended to work inside cryptsetup only! + * Anyway, if some process try to read temporary cryptsetup device, + * it is bug - no other process should try touch it (e.g. udev). + */ +if (force) { + _error_device(options); +retries = RETRY_COUNT; +} + +do { +r = _dm_simple(DM_DEVICE_REMOVE, options->name) ? 0 : -EINVAL; +if (--retries) +sleep(1); +} while (r == -EINVAL && retries); + +dm_task_update_nodes(); + +return r; +} + static int dm_create_device(int reload, struct crypt_options *options, const char *key) { < at >< at > -198,24 +258,14 < at >< at > static int dm_create_device(int reload, if (dmi.read_only) options->flags |= CRYPT_FLAG_READONLY; -/* run udevsettle to avoid a race in libdevmapper causing busy dm devices */ -run_udevsettle(); - r = 0; - out: if (r < 0 && !reload) { char *error = (char *)get_error(); if (error) error = strdup(error); -if (dmt) -dm_task_destroy(dmt); -if (!(dmt = dm_task_create(DM_DEVICE_REMOVE))) -goto out_restore_error; -if (!dm_task_set_name(dmt, options->name)) -goto out_restore_error; -if (!dm_task_run(dmt)) +if (!_dm_remove(options, 0)) goto out_restore_error; out_restore_error: < at >< at > -231,7 +281,7 < at >< at > out_no_removal: dm_task_destroy(dmt); if(dmt_query) dm_task_destroy(dmt_query); -flush_dm_workqueue(); +dm_task_update_nodes(); return r; } < at >< at > -359,25 +409,12 < at >< at > out: return r; } -static int dm_remove_device(struct crypt_options *options) +static int dm_remove_device(int force, struct crypt_options *options) { -struct dm_task *dmt; -int r = -EINVAL; +if (!options || !options->name) +return -EINVAL; -if (!(dmt = dm_task_create(DM_DEVICE_REMOVE))) -goto out; -if (!dm_task_set_name(dmt, options->name)) -goto out; -if (!dm_task_run(dmt)) -goto out; - -r = 0; - -out: -if (dmt) -dm_task_destroy(dmt); -flush_dm_workqueue(); -return r; +return _dm_remove(options, force);; } Index: cryptsetup.my/lib/internal.h =================================================================== --- cryptsetup.my.orig/lib/internal.h2008-09-04 14:17:33.000000000 +0200 +++ cryptsetup.my/lib/internal.h2008-09-04 14:17:36.000000000 +0200 < at >< at > -40,7 +40,7 < at >< at > struct setup_backend { const char *key); int(*status)(int details, struct crypt_options *options, char **key); -int(*remove)(struct crypt_options *options); +int(*remove)(int force, struct crypt_options *options); const char *(*dir)(void); }; Index: cryptsetup.my/lib/setup.c =================================================================== --- cryptsetup.my.orig/lib/setup.c2008-09-04 14:17:33.000000000 +0200 +++ cryptsetup.my/lib/setup.c2008-09-04 14:17:36.000000000 +0200 < at >< at > -369,7 +369,7 < at >< at > static int __crypt_remove_device(int arg return -EBUSY; } -return backend->remove(options); +return backend->remove(0, options); } static int __crypt_luks_format(int arg, struct setup_backend *backend, struct crypt_options *options) Index: cryptsetup.my/luks/keyencryption.c =================================================================== --- cryptsetup.my.orig/luks/keyencryption.c2008-09-04 14:17:33.000000000 +0200 +++ cryptsetup.my/luks/keyencryption.c2008-09-04 14:17:36.000000000 +0200 < at >< at > -50,10 +50,8 < at >< at > static int setup_mapping(const char *cip const char *key, size_t keyLength, unsigned int sector, size_t srcLength, struct setup_backend *backend, - int mode) + int mode, struct crypt_options *options) { -struct crypt_options k; -struct crypt_options *options = &k; int device_sector_size = sector_size_for_device(device); int r; < at >< at > -87,16 +85,14 < at >< at > static int setup_mapping(const char *cip return r; } -static int clear_mapping(const char *name, struct setup_backend *backend) +static int clear_mapping(struct crypt_options *options, struct setup_backend *backend) { -struct crypt_options options; -options.name=name; -return backend->remove(&options); +return backend->remove(1, options); } /* I miss closures in C! */ static struct setup_backend *cleaner_backend=NULL; -static const char *cleaner_name=NULL; +static struct crypt_options *cleaner_options = NULL; static int devfd=-1; static void sigint_handler(int sig) < at >< at > -104,8 +100,8 < at >< at > static void sigint_handler(int sig) if(devfd >= 0) close(devfd); devfd = -1; - if(cleaner_backend && cleaner_name) - clear_mapping(cleaner_name, cleaner_backend); + if(cleaner_backend && cleaner_options) + clear_mapping(cleaner_options, cleaner_backend); signal(SIGINT, SIG_DFL); kill(getpid(), SIGINT); } < at >< at > -120,6 +116,7 < at >< at > static int LUKS_endec_template(char *src ssize_t (*func)(int, void *, size_t), int mode) { +struct crypt_options options = {0}; char *name = NULL; char *fullpath = NULL; char *dmCipherSpec = NULL; < at >< at > -138,10 +135,11 < at >< at > static int LUKS_endec_template(char *src } signal(SIGINT, sigint_handler); -cleaner_name = name; +options.name = name; +cleaner_options = &options; cleaner_backend = backend; -r = setup_mapping(dmCipherSpec,name,device,hdr->payloadOffset,key,keyLength,sector,srcLength,backend,mode); +r = setup_mapping(dmCipherSpec,name,device,hdr->payloadOffset,key,keyLength,sector,srcLength,backend,mode,&options); if(r < 0) { if(!get_error()) set_error("Failed to setup dm-crypt key mapping.\nCheck kernel for support for the %s cipher spec and verify that %s contains at least %d sectors", < at >< at > -163,10 +161,10 < at >< at > static int LUKS_endec_template(char *src close(devfd); devfd = -1; out2: -clear_mapping(name,backend); +clear_mapping(&options,backend); out1: signal(SIGINT, SIG_DFL); -cleaner_name = NULL; +cleaner_options = NULL; cleaner_backend = NULL; free(dmCipherSpec); free(fullpath); 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); + devfd = -1; if(cleaner_backend && cleaner_name) clear_mapping(cleaner_name, cleaner_backend); signal(SIGINT, SIG_DFL); < at >< at > -160,7 +161,7 < at >< at > static int LUKS_endec_template(char *src r = 0; out3: close(devfd); -devfd = 0; +devfd = -1; out2: clear_mapping(name,backend); out1: 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 long as the same key is not used to encrypt much more than 1 terabyte of data. Up until this point, no attack can succeed with probability better than approximately one in eight quadrillion. However this security guarantee deteriorates as more data is encrypted with the same key. With a petabyte the attack success probability rate decreases to *at most* eight in a trillion, with an exabyte, the success probability is reduced to *at most* eight in a million. Essentially this means that using XTS, with one key for more than a few hundred terabytes of data opens up the possibility of attacks (and is not mitigated by using a larger AES key size, so using a 256-bit key doesn't change this). The paper notes that the decision on the maximum amount to data to be encrypted with a single key using XTS should consider the above together with the practical implication of the attack (which is the ability of the adversary to modiy plaintext of a specific block, where the position of this block may not be under the advisary's control). As people do seem to be interested in XTS, I think it may be worth considering performing a simple size of data partition to be encrypted check to see if it is over 1TB and if so, present a warning about this potential problem so that the user can make an informed decision instead of being surprised later. If its not possible to do such a test, or its possible for the user to increase the size of their underlying encrypted volume, then perhaps the warning should be included by default. micah 0. http://grouper.ieee.org/groups/1619tmp/1619-2007-NIST-Submission.pdf (oddly, this is only available until September 3rd, I have a copy if anyone needs it) _______________________________________________ pkg-cryptsetup-devel mailing list pkg-cryptsetup-devel-XbBxUvOt3X2LieD7tvxI8l/i77bcL1HB< at >public.gmane.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cryptsetup-devel ----- End forwarded message ----- 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.c(arbetskopia) < at >< at > -390,7 +390,7 < at >< at > } 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) < at >< at > -23,8 +23,6 < at >< at > closeRandom */ int getRandom(char *buf, size_t len) { - int r = 0; - if(openRandom() == -1) { perror("getRandom:"); return -EINVAL; < at >< at > -37,7 +35,7 < at >< at > } len-= r; buf += r; } - return r; + return 0; } void closeRandom() { Index: luks/keymanage.c =================================================================== --- luks/keymanage.c(revision 58) +++ luks/keymanage.c(arbetskopia) < at >< at > -50,6 +50,7 < at >< at > 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; } < at >< at > -66,7 +67,13 < at >< at > 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; } 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 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 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 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 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 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 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 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 2008-07-22T06:04:58 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2783 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 spammed 2008-07-18T21:04:20 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2779 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All - I have been asked if there is a way to incorporate Microsoft's PKI with dm-crypt. The story here is that with Microsoft's disk encryption, you can decrypt a directory using an organization key. An example is when an employee leaves and does not tell anyone what his/her passphrase was. I know with LUKS it's easy to set up multiple passwords. But is there a way to use an x509 certificate to set up access? Thanks! - -- 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 iD8DBQFIfms0mzle50YHwaARAhnxAKCWghcvwOJaFFLmfOspEeNaGxwt+gCcD0Qn L0PFfceoMY2J7Sk/5N1+7dU= =PS1G -----END PGP SIGNATURE----- Thomas Cameron (Red Hat 2008-07-16T21:42:13 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2775 I want to make a crypted pen drive and see it on windows machines too . Event after vfating ... the new created crypted drive , i was able to see the pen in windows . I did in fat32 . Oh yeah ! There must be a cryptsetup windows version ... Is around a more portable cryptosolution for a pen drive ? gabriele esposito 2008-07-15T02:04:58 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2773 Hi there - Subject says it all really Truecrypt 6.0 just came out and says it's been rewritten to support parallelized encryption/decryption on multi-core processors (or multiprocessors). Is that something dm-crypt supports? Just curious :-) Thanks! Jason Jason Haar 2008-07-08T17:39:57 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2761 Hi, I have encrypted my drive with dm-crypt and Luks. Now what I would like to have is that the volume can only be unlocked with both a password AND a key. So far I have only been able to use a passphrase or just a key, I wonder if it is possible to use both. Kind regards, Rens Rense Buijen 2008-07-08T11:02:01 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2757 Hello, My name is Chris Miceli, and I was recently exposed to a video describing an attack relying on persistent memory (http://news.cnet.com/8301-13578_3-9876060-38.html <http://news.cnet.com/8301-13578_3-9876060-38.html>). I was wondering if dm-crypt has any methods to help protect against this attack. My friend and I are very curious about security techniques and had some input that I was wondering about. Since the encryption key is frequently used (every read and write), it should be stored in the cpu cache. Would there be a way to not keep the key in memory but only in cache, like a TPM. Is this medium of storage and less vulnerable to these attacks? I realize this sacrifices cache space, but the key is probably there anyways. What do you think? Chris Miceli Computer Science Junior, Louisiana State University Chris 2008-06-30T15:54:27 http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2756 Not thinking straight, I did the following: Unmounted all encrypted partitions and then ran dmsetup remove_all, think it would close my encrypted shares. Now when I use cryptsetup, it works fine, but when I go to mount the shares, it doesn't know the file system and I can't specify the correct one. Any ideas how I can fix what I did with dmsetup remove_all? James Whitt 2008-06-17T17:38:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.device-mapper.dm-crypt