* [linux-lvm] DM encryption target? @ 2003-09-23 11:02 Greg Freemyer 2003-09-23 12:08 ` Kevin Corry 2003-09-23 14:02 ` Christophe Saout 0 siblings, 2 replies; 15+ messages in thread From: Greg Freemyer @ 2003-09-23 11:02 UTC (permalink / raw) To: linux-lvm There was talk about creating a DM encrypting target a while ago. Did this ever proceed? Greg -- Greg Freemyer ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-23 11:02 [linux-lvm] DM encryption target? Greg Freemyer @ 2003-09-23 12:08 ` Kevin Corry 2003-09-23 11:55 ` Greg Freemyer 2003-09-23 14:02 ` Christophe Saout 1 sibling, 1 reply; 15+ messages in thread From: Kevin Corry @ 2003-09-23 12:08 UTC (permalink / raw) To: linux-lvm, Greg Freemyer On Tuesday 23 September 2003 10:51, Greg Freemyer wrote: > There was talk about creating a DM encrypting target a while ago. > > Did this ever proceed? > > Greg You can read through the discussions about dm-crypt in the dm-devel archives, starting at: http://lists.sistina.com/pipermail/dm-devel/2003-July/thread.html Christophe Saout has a dm-crypt module available at: http://www.saout.de/misc/ -- Kevin Corry kevcorry@us.ibm.com http://evms.sourceforge.net/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-23 12:08 ` Kevin Corry @ 2003-09-23 11:55 ` Greg Freemyer 0 siblings, 0 replies; 15+ messages in thread From: Greg Freemyer @ 2003-09-23 11:55 UTC (permalink / raw) To: Kevin Corry; +Cc: linux-lvm On Tue, 2003-09-23 at 12:12, Kevin Corry wrote: > On Tuesday 23 September 2003 10:51, Greg Freemyer wrote: > > There was talk about creating a DM encrypting target a while ago. > > > > Did this ever proceed? > > > > Greg > > You can read through the discussions about dm-crypt in the dm-devel archives, > starting at: > http://lists.sistina.com/pipermail/dm-devel/2003-July/thread.html > > Christophe Saout has a dm-crypt module available at: > http://www.saout.de/misc/ Thanks, I don't follow dm-devel so I missed that whole thread. Greg ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-23 11:02 [linux-lvm] DM encryption target? Greg Freemyer 2003-09-23 12:08 ` Kevin Corry @ 2003-09-23 14:02 ` Christophe Saout 2003-09-24 6:21 ` Jon Bendtsen 1 sibling, 1 reply; 15+ messages in thread From: Christophe Saout @ 2003-09-23 14:02 UTC (permalink / raw) To: Greg Freemyer; +Cc: linux-lvm Am Di, 2003-09-23 um 17.51 schrieb Greg Freemyer: > There was talk about creating a DM encrypting target a while ago. > > Did this ever proceed? Yes, as Kevin already pointed out, I've written a working implementation some time ago. It currently seems to be more stable than the cryptoloop implementation in the 2.6-test kernels. You can find my original announcement with some how-to-use details at http://lwn.net/Articles/42000/ . Don't use that patch, I've got a newer one one my homepage http://www.saout.de/misc/dm-crypt.diff . -- Christophe Saout <christophe@saout.de> Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-23 14:02 ` Christophe Saout @ 2003-09-24 6:21 ` Jon Bendtsen 2003-09-24 7:00 ` Christophe Saout 0 siblings, 1 reply; 15+ messages in thread From: Jon Bendtsen @ 2003-09-24 6:21 UTC (permalink / raw) To: linux-lvm Christophe Saout wrote: > Am Di, 2003-09-23 um 17.51 schrieb Greg Freemyer: > > >>There was talk about creating a DM encrypting target a while ago. >> >>Did this ever proceed? > > > Yes, as Kevin already pointed out, I've written a working implementation > some time ago. It currently seems to be more stable than the cryptoloop > implementation in the 2.6-test kernels. > > You can find my original announcement with some how-to-use details at > http://lwn.net/Articles/42000/ . Don't use that patch, I've got a newer > one one my homepage http://www.saout.de/misc/dm-crypt.diff . How far did you come? Can you change the password? What kind of encryption can be used? the hole cryptoapi range? just some? JonB ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-24 6:21 ` Jon Bendtsen @ 2003-09-24 7:00 ` Christophe Saout 2003-09-24 9:53 ` jon+lvm 2003-09-25 8:03 ` Goetz Bock 0 siblings, 2 replies; 15+ messages in thread From: Christophe Saout @ 2003-09-24 7:00 UTC (permalink / raw) To: linux-lvm Am Mi, 2003-09-24 um 13.25 schrieb Jon Bendtsen: > > Yes, as Kevin already pointed out, I've written a working implementation > > some time ago. It currently seems to be more stable than the cryptoloop > > implementation in the 2.6-test kernels. > > > > You can find my original announcement with some how-to-use details at > > http://lwn.net/Articles/42000/ . Don't use that patch, I've got a newer > > one one my homepage http://www.saout.de/misc/dm-crypt.diff . > > How far did you come? Can you change the password? What kind of > encryption can be used? the hole cryptoapi range? just some? Every (symmetrical, well, there are only symmetrical ciphers in the kernel ATM) cipher can be used with every possible key size. At least in theory, I tried some combinations and everything worked as expected. The cryptoapi use is relatively independent of the cipher used. The target has no in-place-conversion support (what I suppose you mean with password change?). If someone wants to do this you would probably do this offline or need another target for this (probably similar to the pvmove mechanism). I've thought of a way to do this completely in userspace. I've got a test program running, but when doing IO on the device while conversion is running it tends to lock up. I don't know why exactly, probably my idea is flawed (at least I think it's dangerous under low memory conditions). It was just an experiment anyway. If someone is interested in the source, please say so. Another way to do a password change would be to not reencrypt the device but to store the symmetrical key somewhere else and encrypt it with a password hash and to just reencrypt that key with another password. But this one could be done completely userspace. I've not written a special dmcryptsetup tool for this, where this should probably go (or be integrated into the lvm tools, whatever). You have to use dmsetup at the moment. -- Christophe Saout <christophe@saout.de> Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-24 7:00 ` Christophe Saout @ 2003-09-24 9:53 ` jon+lvm 2003-09-25 8:03 ` Goetz Bock 1 sibling, 0 replies; 15+ messages in thread From: jon+lvm @ 2003-09-24 9:53 UTC (permalink / raw) To: linux-lvm On Wed, Sep 24, 2003 at 01:59:36PM +0200, Christophe Saout wrote: > Am Mi, 2003-09-24 um 13.25 schrieb Jon Bendtsen: [cut] > Another way to do a password change would be to not reencrypt the device > but to store the symmetrical key somewhere else and encrypt it with a > password hash and to just reencrypt that key with another password. this is what we use in our approach. But it's not quite ready yet. Hint... store the key atleast 2 places... JonB ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] DM encryption target? 2003-09-24 7:00 ` Christophe Saout 2003-09-24 9:53 ` jon+lvm @ 2003-09-25 8:03 ` Goetz Bock 2003-09-25 11:09 ` [linux-lvm] RFC: " Christophe Saout 1 sibling, 1 reply; 15+ messages in thread From: Goetz Bock @ 2003-09-25 8:03 UTC (permalink / raw) To: linux-lvm On Wed, Sep 24 '03 at 13:59, Christophe Saout wrote: > Another way to do a password change would be to not reencrypt the device > but to store the symmetrical key somewhere else and encrypt it with a > password hash and to just reencrypt that key with another password. That would be nice, just use the first block for the key (giving you 512byte keysize, and you can generate a realy strong key[*]). Just in idea. [*] yes, i know it's only as strong as the user's password. Security is only as good as it's weekest link, and in the end that's always the user. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2003 as GNU FDL 1.1 X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] ^ permalink raw reply [flat|nested] 15+ messages in thread
* [linux-lvm] RFC: DM encryption target? 2003-09-25 8:03 ` Goetz Bock @ 2003-09-25 11:09 ` Christophe Saout 2003-09-26 7:50 ` jon+lvm 0 siblings, 1 reply; 15+ messages in thread From: Christophe Saout @ 2003-09-25 11:09 UTC (permalink / raw) To: linux-lvm Am Mi, den 24.09.2003 schrieb Goetz Bock um 16:21: > > Another way to do a password change would be to not reencrypt the device > > but to store the symmetrical key somewhere else and encrypt it with a > > password hash and to just reencrypt that key with another password. > That would be nice, just use the first block for the key (giving you > 512byte keysize, and you can generate a realy strong key[*]). > > Just in idea. > > [*] yes, i know it's only as strong as the user's password. > Security is only as good as it's weekest link, and in the end > that's always the user. I don't know, but couldn't the use of a one-sector block slow things down because of alignment issues? Perhaps using a 4k block would be more useful or storing the sector at the end of the device (like the linux raid info sector). I think that 512 bytes / 4096 bits should really be enough to store the keys. I could store the data in a simple text format, starting with a magic header. Something like: #CrYpT version = 1 cipher = "aes" mode = "cbc" keysize = 256 pwdsalt = "0e3a5b4c" pwdhash = "md5" pwdenc = "3des" key = "8e3eb...blabla..." hash = "23e4f" node = "/dev/mapper/crypt" offset = ...useful? size = ...useful? A userspace program (dmcryptsetup) could be called like dmcryptsetup /dev/hda5 It would then detect this sector at the end of that device, reads it, asks the user for a password, combines it with the salt, hashes it (with the given algorithm) and uses the result to decrypt the key. Then it checks if the hash of the decrypted key matches the given one to be sure that the key is the correct one. Perhaps a public key encryption or something could also be useful (e.g. if you have a private key on some usb stick to mount your partition?) I'm really no crypto expert, but does this sound reasonable? Additional lightweight / compatibility options could be to use a hashed password directly as key, without this "key info sector" or to give the key directly to the setup program. Since the program would be userspace it would be linked to libcrypto (from openssl) to get additional needed digests/ciphers for key management. Does this sound ok? -- Christophe Saout <christophe@saout.de> Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] RFC: DM encryption target? 2003-09-25 11:09 ` [linux-lvm] RFC: " Christophe Saout @ 2003-09-26 7:50 ` jon+lvm 2003-09-26 8:05 ` Christophe Saout 2003-09-26 14:16 ` Greg Freemyer 0 siblings, 2 replies; 15+ messages in thread From: jon+lvm @ 2003-09-26 7:50 UTC (permalink / raw) To: linux-lvm On Thu, Sep 25, 2003 at 06:07:58PM +0200, Christophe Saout wrote: > Am Mi, den 24.09.2003 schrieb Goetz Bock um 16:21: > > > > Another way to do a password change would be to not reencrypt the device > > > but to store the symmetrical key somewhere else and encrypt it with a > > > password hash and to just reencrypt that key with another password. > > That would be nice, just use the first block for the key (giving you > > 512byte keysize, and you can generate a realy strong key[*]). > > > > Just in idea. > > > > [*] yes, i know it's only as strong as the user's password. > > Security is only as good as it's weekest link, and in the end > > that's always the user. > > I don't know, but couldn't the use of a one-sector block slow things > down because of alignment issues? Perhaps using a 4k block would be more > useful or storing the sector at the end of the device (like the linux > raid info sector). maybe, but does it matter? You only read the sector once, when you "open" the device, and write to it when you change password. During use, the real key is stored in memory, like any other encryption device. > I think that 512 bytes / 4096 bits should really be enough to store the > keys. > > I could store the data in a simple text format, starting with a magic > header. Something like: > > #CrYpT > version = 1 > cipher = "aes" > mode = "cbc" > keysize = 256 > pwdsalt = "0e3a5b4c" > pwdhash = "md5" > pwdenc = "3des" > key = "8e3eb...blabla..." > hash = "23e4f" > node = "/dev/mapper/crypt" > offset = ...useful? > size = ...useful? this could be usefull > I'm really no crypto expert, but does this sound reasonable? yes, see how ppdd does it, or, in one week how me and my friend does it. JonB ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] RFC: DM encryption target? 2003-09-26 7:50 ` jon+lvm @ 2003-09-26 8:05 ` Christophe Saout 2003-09-29 8:07 ` Goetz Bock 2003-09-26 14:16 ` Greg Freemyer 1 sibling, 1 reply; 15+ messages in thread From: Christophe Saout @ 2003-09-26 8:05 UTC (permalink / raw) To: linux-lvm Am Fr, den 26.09.2003 schrieb jon+lvm@silicide.dk um 14:48: > > I don't know, but couldn't the use of a one-sector block slow things > > down because of alignment issues? Perhaps using a 4k block would be more > > useful or storing the sector at the end of the device (like the linux > > raid info sector). > > maybe, but does it matter? You only read the sector once, when you "open" > the device, and write to it when you change password. During use, the real > key is stored in memory, like any other encryption device. No, I meant the following: Let's assume you are using crypto on a raid 0/5 device or something. Usually the filesystem uses 4k blocks. Those blocks would normally never span across two stripes because they are aligned. With a crypto device that uses the first sector now all filesystem blocks get moved by one sector so that there are a lot of blocks that span underlying stripes. A lot of harddisks these days use internal blocks that are larger than 512 bytes so there are also alignment issues. That's why I meant that either this info block should be larger than one sector or it should be moved to the end (and the linux md code does it). -- Christophe Saout <christophe@saout.de> Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] RFC: DM encryption target? 2003-09-26 8:05 ` Christophe Saout @ 2003-09-29 8:07 ` Goetz Bock 2003-09-29 8:40 ` jon+lvm 0 siblings, 1 reply; 15+ messages in thread From: Goetz Bock @ 2003-09-29 8:07 UTC (permalink / raw) To: linux-lvm On Fri, Sep 26 '03 at 15:04, Christophe Saout wrote: > Am Fr, den 26.09.2003 schrieb jon+lvm@silicide.dk um 14:48: > > > > I don't know, but couldn't the use of a one-sector block slow things > > > down because of alignment issues? Perhaps using a 4k block would be more > > > useful or storing the sector at the end of the device (like the linux > > > raid info sector). > > > > maybe, but does it matter? > > No, I meant the following: Let's assume you are using crypto on a raid > 0/5 device or something. Usually the filesystem uses 4k blocks. > [ ... ] A lot of harddisks these days use internal blocks that are > larger than 512 bytes so there are also alignment issues. While I don't have any idea how harddisks work internaly thise days, I've no problem to loose 4k or even 16k if it improves anything. But I would still like to get it to the beginning of the partition/drive/device. Mainly to be able to do less -f $DEVICE to figure out what it's all about. I do this more often than not and hate it if all i get back is just binary garbage. Everyfile should tell me what is is for/from in plain text. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2003 as GNU FDL 1.1 X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] RFC: DM encryption target? 2003-09-29 8:07 ` Goetz Bock @ 2003-09-29 8:40 ` jon+lvm 0 siblings, 0 replies; 15+ messages in thread From: jon+lvm @ 2003-09-29 8:40 UTC (permalink / raw) To: linux-lvm On Fri, Sep 26, 2003 at 11:46:17PM +0200, Goetz Bock wrote: > > Mainly to be able to do > > less -f $DEVICE > > to figure out what it's all about. I do this more often than not and > hate it if all i get back is just binary garbage. hmm, i can see your point, and if one steals a hole page there is space enough to write even in cleartext. JonB ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] RFC: DM encryption target? 2003-09-26 7:50 ` jon+lvm 2003-09-26 8:05 ` Christophe Saout @ 2003-09-26 14:16 ` Greg Freemyer 2003-09-27 8:35 ` jon+lvm 1 sibling, 1 reply; 15+ messages in thread From: Greg Freemyer @ 2003-09-26 14:16 UTC (permalink / raw) To: linux-lvm Christophe / Jon, Are either of your code bases compatible with 2.4? Greg -- Greg Freemyer On Fri, 2003-09-26 at 08:48, jon+lvm@silicide.dk wrote: > On Thu, Sep 25, 2003 at 06:07:58PM +0200, Christophe Saout wrote: > > Am Mi, den 24.09.2003 schrieb Goetz Bock um 16:21: > > > > > > Another way to do a password change would be to not reencrypt the device > > > > but to store the symmetrical key somewhere else and encrypt it with a > > > > password hash and to just reencrypt that key with another password. > > > That would be nice, just use the first block for the key (giving you > > > 512byte keysize, and you can generate a realy strong key[*]). > > > > > > Just in idea. > > > > > > [*] yes, i know it's only as strong as the user's password. > > > Security is only as good as it's weekest link, and in the end > > > that's always the user. > > > > I don't know, but couldn't the use of a one-sector block slow things > > down because of alignment issues? Perhaps using a 4k block would be more > > useful or storing the sector at the end of the device (like the linux > > raid info sector). > > maybe, but does it matter? You only read the sector once, when you "open" > the device, and write to it when you change password. During use, the real > key is stored in memory, like any other encryption device. > > > > I think that 512 bytes / 4096 bits should really be enough to store the > > keys. > > > > I could store the data in a simple text format, starting with a magic > > header. Something like: > > > > #CrYpT > > version = 1 > > cipher = "aes" > > mode = "cbc" > > keysize = 256 > > pwdsalt = "0e3a5b4c" > > pwdhash = "md5" > > pwdenc = "3des" > > key = "8e3eb...blabla..." > > hash = "23e4f" > > node = "/dev/mapper/crypt" > > offset = ...useful? > > size = ...useful? > > this could be usefull > > > > I'm really no crypto expert, but does this sound reasonable? > > yes, see how ppdd does it, or, in one week how me and my friend does it. > > > > > JonB > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-lvm] RFC: DM encryption target? 2003-09-26 14:16 ` Greg Freemyer @ 2003-09-27 8:35 ` jon+lvm 0 siblings, 0 replies; 15+ messages in thread From: jon+lvm @ 2003-09-27 8:35 UTC (permalink / raw) To: linux-lvm On Fri, Sep 26, 2003 at 03:06:29PM -0400, Greg Freemyer wrote: > Christophe / Jon, > > Are either of your code bases compatible with 2.4? Dunno, ours are develloped using 2.5.73, and we'll proberly release it on wednesday 1. october. We might miss some tools though. As for speed... we havent testet yet. JonB ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-09-29 8:40 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-09-23 11:02 [linux-lvm] DM encryption target? Greg Freemyer 2003-09-23 12:08 ` Kevin Corry 2003-09-23 11:55 ` Greg Freemyer 2003-09-23 14:02 ` Christophe Saout 2003-09-24 6:21 ` Jon Bendtsen 2003-09-24 7:00 ` Christophe Saout 2003-09-24 9:53 ` jon+lvm 2003-09-25 8:03 ` Goetz Bock 2003-09-25 11:09 ` [linux-lvm] RFC: " Christophe Saout 2003-09-26 7:50 ` jon+lvm 2003-09-26 8:05 ` Christophe Saout 2003-09-29 8:07 ` Goetz Bock 2003-09-29 8:40 ` jon+lvm 2003-09-26 14:16 ` Greg Freemyer 2003-09-27 8:35 ` jon+lvm
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.