[linux-lvm] DM encryption target?

[linux-lvm] DM encryption target?

[Greg Freemyer]

There was talk about creating a DM encrypting target a while ago.

Did this ever proceed?

Greg
-- 
Greg Freemyer

Re: [linux-lvm] DM encryption target?

[Kevin Corry]

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/

Re: [linux-lvm] DM encryption target?

[Greg Freemyer]

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

Re: [linux-lvm] DM encryption target?

[Christophe Saout]

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

Re: [linux-lvm] DM encryption target?

[Jon Bendtsen]

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

Re: [linux-lvm] DM encryption target?

[Christophe Saout]

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

Re: [linux-lvm] DM encryption target?

[jon+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

Re: [linux-lvm] DM encryption target?

[Goetz Bock]

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 ]

[linux-lvm] RFC: DM encryption target?

[Christophe Saout]

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

Re: [linux-lvm] RFC: DM encryption target?

[jon+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 

Re: [linux-lvm] RFC: DM encryption target?

[Christophe Saout]

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

Re: [linux-lvm] RFC: DM encryption target?

[Goetz Bock]

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 ]

Re: [linux-lvm] RFC: DM encryption target?

[jon+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

Re: [linux-lvm] RFC: DM encryption target?

[Greg Freemyer]

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/

Re: [linux-lvm] RFC: DM encryption target?

[jon+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