Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
> Dunno here, seems that having one tool that gave the kernel a key named
> "foo" and then telling dm-crypt to use key "foo" is probably not a bad
> way to go. Then we don't have stuff like "echo | dmsetup create"
> and the like and
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
> Way too complicated. This is a crypto project, why does nobody think of
> crypto to solve the problem :). Here's the idea:
> [see original post, http://lkml.org/lkml/2005/2/3/109 , for idea]
Very simple patch. With that, it's
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
Way too complicated. This is a crypto project, why does nobody think of
crypto to solve the problem :). Here's the idea:
[see original post, http://lkml.org/lkml/2005/2/3/109 , for idea]
Very simple patch. With that, it's
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
Dunno here, seems that having one tool that gave the kernel a key named
foo and then telling dm-crypt to use key foo is probably not a bad
way to go. Then we don't have stuff like echo key | dmsetup create
and the like and the
Hi!
> > # dmsetup table /dev/mapper/volume1
> > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
>
> > Obviously, root can in principle recover this password from the
> > running kernel but it seems silly to make it so easy.
>
> There seemed little point obfuscating it -
On Thu, 2005-02-03 at 05:15 -0500, Christopher Warner wrote:
> On Thu, 2005-02-03 at 15:18 +0100, Fruhwirth Clemens wrote:
> >
> > Keys are handed to dm-crypt regularly the first time. But when dm-crypt
> > hands keys back to user space, it uses some sort of blinding to make the
> > keys
On Thu, 2005-02-03 at 15:18 +0100, Fruhwirth Clemens wrote:
> On Wed, 2005-02-02 at 20:05 -0800, Matt Mackall wrote:
>
> > Dunno here, seems that having one tool that gave the kernel a key named
> > "foo" and then telling dm-crypt to use key "foo" is probably not a bad
> > way to go. Then we
On Thu, 2005-02-03 at 15:47 +0100, Andries Brouwer wrote:
> On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
>
> > (Actually it's a Multi Time Pad.)
>
> And you call this "crypto"?
Is the quoted part all you have read?
--
Fruhwirth Clemens <[EMAIL PROTECTED]>
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
> (Actually it's a Multi Time Pad.)
And you call this "crypto"?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, 2005-02-02 at 20:05 -0800, Matt Mackall wrote:
> Dunno here, seems that having one tool that gave the kernel a key named
> "foo" and then telling dm-crypt to use key "foo" is probably not a bad
> way to go. Then we don't have stuff like "echo | dmsetup create"
> and the like and the
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
> On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
> > The keyring API seems very flexible. You can define your own type of
> > keys and give them names. Well, the name is probably irrelevant here and
> > should be
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
The keyring API seems very flexible. You can define your own type of
keys and give them names. Well, the name is probably irrelevant here and
should be chosen
On Wed, 2005-02-02 at 20:05 -0800, Matt Mackall wrote:
Dunno here, seems that having one tool that gave the kernel a key named
foo and then telling dm-crypt to use key foo is probably not a bad
way to go. Then we don't have stuff like echo key | dmsetup create
and the like and the
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
(Actually it's a Multi Time Pad.)
And you call this crypto?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 2005-02-03 at 15:47 +0100, Andries Brouwer wrote:
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
(Actually it's a Multi Time Pad.)
And you call this crypto?
Is the quoted part all you have read?
--
Fruhwirth Clemens [EMAIL PROTECTED]
On Thu, 2005-02-03 at 15:18 +0100, Fruhwirth Clemens wrote:
On Wed, 2005-02-02 at 20:05 -0800, Matt Mackall wrote:
Dunno here, seems that having one tool that gave the kernel a key named
foo and then telling dm-crypt to use key foo is probably not a bad
way to go. Then we don't have stuff
On Thu, 2005-02-03 at 05:15 -0500, Christopher Warner wrote:
On Thu, 2005-02-03 at 15:18 +0100, Fruhwirth Clemens wrote:
Keys are handed to dm-crypt regularly the first time. But when dm-crypt
hands keys back to user space, it uses some sort of blinding to make the
keys meaningless for
Hi!
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
Obviously, root can in principle recover this password from the
running kernel but it seems silly to make it so easy.
There seemed little point obfuscating it - someone will
On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
> The keyring API seems very flexible. You can define your own type of
> keys and give them names. Well, the name is probably irrelevant here and
> should be chosen randomly but it's less likely to collide with someone
> else.
Am Mittwoch, den 02.02.2005, 17:52 -0800 schrieb Matt Mackall:
> > An alternativ would be to use some form of handle to point to the key
> > after it has been given to the kernel. But that would require some more
> > infrastructure.
>
> There's been some talk about such infrastructure already. I
On Thu, Feb 03, 2005 at 02:33:01AM +0100, Christophe Saout wrote:
> Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
>
> > From looking at the dm_crypt code, it appears that it can be
> > interrogated to report the current key. Some quick testing shows:
> >
> > # dmsetup table
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
> From looking at the dm_crypt code, it appears that it can be
> interrogated to report the current key. Some quick testing shows:
>
> # dmsetup table /dev/mapper/volume1
> 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0
On Wed, Feb 02, 2005 at 11:50:02PM +, Alasdair G Kergon wrote:
> On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote:
> > # dmsetup table /dev/mapper/volume1
> > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
>
> > Obviously, root can in principle recover this
On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote:
> # dmsetup table /dev/mapper/volume1
> 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
> Obviously, root can in principle recover this password from the
> running kernel but it seems silly to make it so easy.
>From looking at the dm_crypt code, it appears that it can be
interrogated to report the current key. Some quick testing shows:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
Obviously, root can in principle recover this password from the
From looking at the dm_crypt code, it appears that it can be
interrogated to report the current key. Some quick testing shows:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
Obviously, root can in principle recover this password from the
On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
Obviously, root can in principle recover this password from the
running kernel but it seems silly to make it so easy.
There
On Wed, Feb 02, 2005 at 11:50:02PM +, Alasdair G Kergon wrote:
On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
Obviously, root can in principle recover this password
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
From looking at the dm_crypt code, it appears that it can be
interrogated to report the current key. Some quick testing shows:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0
On Thu, Feb 03, 2005 at 02:33:01AM +0100, Christophe Saout wrote:
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
From looking at the dm_crypt code, it appears that it can be
interrogated to report the current key. Some quick testing shows:
# dmsetup table
Am Mittwoch, den 02.02.2005, 17:52 -0800 schrieb Matt Mackall:
An alternativ would be to use some form of handle to point to the key
after it has been given to the kernel. But that would require some more
infrastructure.
There's been some talk about such infrastructure already. I believe
On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
The keyring API seems very flexible. You can define your own type of
keys and give them names. Well, the name is probably irrelevant here and
should be chosen randomly but it's less likely to collide with someone
else.
Dunno
32 matches
Mail list logo
