From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.5) Gecko/20041220 Epiphany/1.4.7 Description of problem: Clemens Fruhwirth has done some work adding functionality to cryptsetup as part of his Linux Unified Key Setup system. LUKS provides anti-forensic techniques and allows one to store crypto parameters before the filesystem on a disk. LUKS is implemented as a patch to cryptsetup. Information about LUKS may be found at http://clemens.endorphin.org/LUKS. LUKS is being used to add encrypted disk support to HAL. See David Zeuthen's notes at: http://lists.freedesktop.org/archives/hal/2004-December/001423.html Note that right now, the proposed sesame filesystem header is being replaced by the existing LUKS header. This is all bleeding edge stuff but we are working on it. LUKS itself is approaching 1.0. Version-Release number of selected component (if applicable): cryptsetup-0.1-4 How reproducible: Always Steps to Reproduce: Notice cryptsetup does not contain the LUKS patch. "cryptsetup isLuks /dev/sda1" fails. Additional info:
Some comments from Clemens Fruhwirth that I just received via. the dm-crypt mailing list: >> is there a LUKS patch for cryptsetup? > No. At first it was a patch, but obviously patching was to > cumbersome for many users, so I created a package. Then, Christophe > told me he is too busy for merge activity, so I dropped the patch > entirely. > cryptsetup-luks is a superset of cryptsetup in terms of > functionality, and is intended as replacement for the original > cryptsetup (as it has the same binary names). >> What version from crypsetup does the cryptsetup on your site >> inherent from? > cryptsetup-luks forked of 0.2-pre CVS.
Created attachment 110976 [details] SRPM for cryptsetup-luks This SRPM will build cryptsetup-luks-0.993. I choose to name the package cryptsetup-luks and have it obsolete cryptsetup. At this point it is unclear if cryptsetup-luks will ever become cryptsetup (see above). The package builds a static executable and installs it in /sbin.
cryptsetup-luks-0.993-1 added. Note that what we're shipping is specifically *not* packaging the library; I checked with Clemens, and he says that cryptsetup is the only thing that uses the library interface, so there's not really much use in shipping the shared lib/headers now.
Version 1.0 of cryptsetup-luks is available. In terms of functionallity, there is no big difference to 0.993. The 1.0 version is rather a last-polish release. Changelog: * Man page added. * Rename luksInit to luksFormat. * Changed default LUKS key bits to 128. * LUKS dump command Also, there is a safety check for the luksFormat command aka "Are you really really sure?" to prevent users from accidentally shooting themselfs in the foot. btw. thanks for packaging that so quickly.
oh, one thing I forgot: It's available from http://luks.endorphin.org/dm-crypt
Built, thanks.
With regards to comment #3: one thing that does use the cryptsetup libraries is the util-linux patch. See bug #56698. Could these libraries be included in the package?
Karel, are you intending to add the patch from 56698, or not until it's upstream?
Upstream of course. I will inform you of the real requirement of the library.
OK. Pulling off the target list until the util-linux patch is upstream.
Karel, I've been working on util-linux myself a few years ago. I've written 3 entire different patch sets to include crypto into util-linux. None of them was included. With 2.12 the util-linux maintainer published with totally broken encryption support written on his own. My last patch to remedy this "brokeness" was from 2003. The latest 2005 release still does not work in any useful way. Conclusion: Forget about util-linux. It is totally useless for encryption, and it is becoming more meaningless as the new stuff happens on dm-crypt anyway. Why should anyone use a none-native tool?
Is cryptsetup-luks supposed to be backwards compatable? I had a crypted disk set up on FC3, it was set up like this: openssl rand -base64 32 | gpg -c --cipher-algo \ AES256 > /root/mnt.key /usr/bin/gpg -q --cipher-algo AES256 --decrypt /root/mnt.key \ | /sbin/cryptsetup -v --key-size=256 --cipher=aes-cbc-essiv:sha256 \ create home /dev/hda3 mount /dev/mapper/home /home I upgraded to FC4 and the above no longer worked -- no errors from cryptsetup-luks but mount refused to mount the disk. I did a rpm -e cryptsetup-luks and installed the FC3 cryptsetup and now I can mount this disk again. This might not be a bug...?
I just found this: At the moment there is no way, to convert to LUKS with an in-place dd. http://luks.endorphin.org/dm-crypt So I guess this isn't a bug :-)
Actually this might be a bug, perhaps this is the problem I have had, the latest release (1.01) has this in the email announcement: * Fixed hash inconsistancy bug between cryptsetup-luks and original for piped passwords. <at> Bill: you might want to bump this into Fedora soon, as many fedora users seem to be unpleasantly surprised by this because of the cryptsetup->cryptsetup-luks switch. http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/1030
Bill, enable the library in FC development branch, please. I'm going to play with it. The util-linux upstream is inactive so I'm going to resolve it myself in FC5. Thanks.
Should be there in the devel branch in 1.0.1-1.