DM encryption target?
There was talk about creating a DM encrypting target a while ago.
Did this ever proceed?
Greg
Signature · 1 line
Greg Freemyer
Quoted 5 lines · Greg Freemyer
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/
Signature · 3 lines
Kevin Corry [email protected] http://evms.sourceforge.net/
Quoted 5 lines · Kevin Corry
Quoted 4 lines · Greg Freemyer
There was talk about creating a DM encrypting target a while ago.
Did this ever proceed?
Quoted 8 lines
Quoted 1 line
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.htmlChristophe 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
Am Di, 2003-09-23 um 17.51 schrieb Greg Freemyer:
Quoted 3 lines
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 <[email protected]>
Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Quoted 8 lines · Christophe Saout
Am Di, 2003-09-23 um 17.51 schrieb Greg Freemyer:
Quoted 3 lines
There was talk about creating a DM encrypting target a while ago.
Did this ever proceed?
Quoted 7 lines
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
Am Mi, 2003-09-24 um 13.25 schrieb Jon Bendtsen:
Quoted 10 lines
Quoted 7 lines
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 <[email protected]>
Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Quoted 1 line · Christophe Saout
Am Mi, 2003-09-24 um 13.25 schrieb Jon Bendtsen:
[cut]
Quoted 3 lines
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
Quoted 3 lines · Christophe Saout
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.
Signature · 4 lines
/"\ 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?
Am Mi, den 24.09.2003 schrieb Goetz Bock um 16:21:
Quoted 11 lines
Quoted 3 lines
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 <[email protected]>
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?
Quoted 10 lines · Christophe Saout
Am Mi, den 24.09.2003 schrieb Goetz Bock um 16:21:
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
[*] 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.
Quoted 6 lines
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:
Quoted 13 lines
#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
Quoted 1 line
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?
Am Fr, den 26.09.2003 schrieb [email protected] um 14:48:
Quoted 8 lines
Quoted 4 lines
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 <[email protected]>
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?
Quoted 7 lines · Christophe Saout
Am Fr, den 26.09.2003 schrieb [email protected] um 14:48:
Quoted 5 lines
Quoted 4 lines
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).
Quoted 6 lines
Quoted 1 line
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.
Signature · 4 lines
/"\ 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?
Quoted 7 lines · Goetz Bock
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?
In reply to [email protected]Christophe / Jon,
Are either of your code bases compatible with 2.4?
Greg
Signature · 1 line
Greg Freemyer
Quoted 62 lines · On Fri, 2003-09-26 at 08:48, [email protected] wrote:
Quoted 10 lines · Christophe Saout
Am Mi, den 24.09.2003 schrieb Goetz Bock um 16:21:
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
[*] 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.
Quoted 6 lines
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:
Quoted 13 lines
#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
Quoted 1 line
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
[email protected]
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?
Quoted 3 lines · Greg Freemyer
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