(Please don't trim me from the CC list if you're replying to what I've said,
thanks.)
On Thu, March 22, 2007 00:31, David Schwartz wrote:
>> If you can't read protect your kernel, you can't write protect it
>> either.
>
> This is so misleading as to basically be false.
Please elaborate. Short of
On Wed, March 21, 2007 16:50, Tasos Parisinos wrote:
A malicious person may want to alter code on the detachable (and unsafe)
file system.
Lots of stuff including the kernel will be in a trapped casing (opening,
probing it, power
analyzing it, heating it etc will result in system suicide
On Wed, March 21, 2007 16:50, Tasos Parisinos wrote:
A malicious person may want to alter code on the detachable (and unsafe)
file system.
Lots of stuff including the kernel will be in a trapped casing (opening,
probing it, power
analyzing it, heating it etc will result in system suicide
(Please don't trim me from the CC list if you're replying to what I've said,
thanks.)
On Thu, March 22, 2007 00:31, David Schwartz wrote:
If you can't read protect your kernel, you can't write protect it
either.
This is so misleading as to basically be false.
Please elaborate. Short of ROM I
> If you can't read protect your kernel, you can't write protect it
> either.
This is so misleading as to basically be false.
It is true that any security scheme that can prevent people from taking
money out of my account can also prevent people from putting money in.
However, the set of people
On Wed, March 21, 2007 16:50, Tasos Parisinos wrote:
> A malicious person may want to alter code on the detachable (and unsafe)
> file system.
> Lots of stuff including the kernel will be in a trapped casing (opening,
> probing it, power
> analyzing it, heating it etc will result in system suicide
I agree that you have no more security that using symmetric
but we believe you have lower costs, simpler key management
(which is a big headache alone), tougher to break through
(not unbreakable) and more centralization
It depends a bit on who you want to give control over what can and
On Wed, March 21, 2007 15:31, Tasos Parisinos wrote:
> Indan Zupancic wrote:
>> On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
>>> How can one tamper (write) the kernel memory of a booted and running kernel
>>> without using an exploitable bug?
>>>
>>> I mean, you can't mess with the bzImage
on the previous message the exponent is not 32 bits but 64 bits, sorry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Indan Zupancic wrote:
On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Protecting a TripleDES key in high security standards is not as
simple as making the kernel read
protected, you need a whole lot and
that also means
On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
>
>> On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
>>
>>> Protecting a TripleDES key in high security standards is not as
>>> simple as making the kernel read
>>> protected, you need a whole lot and
>>> that also means hardware
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Protecting a TripleDES key in high security standards is not as
simple as making the kernel read
protected, you need a whole lot and
that also means hardware (cryptomemories e.t.c)
So you forget about all this overhead when you use
On Wed, March 21, 2007 13:34, Tasos Parisinos wrote:
> Indan Zupancic wrote:
>>> Protecting a TripleDES key in high security standards is not as simple as
>>> making the kernel
>>> read protected, you need a whole lot and that also means hardware
>>> (cryptomemories e.t.c)
>>> So you forget
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
> Protecting a TripleDES key in high security standards is not as
> simple as making the kernel read
> protected, you need a whole lot and
> that also means hardware (cryptomemories e.t.c)
> So you forget about all this overhead when you use
Indan Zupancic wrote:
Protecting a TripleDES key in high security standards is not as simple as
making the kernel
read protected, you need a whole lot and that also means hardware
(cryptomemories e.t.c)
So you forget about all this overhead when you use assymetric
You need to protect
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
>> Assuming you have a secure kernel binary that is tamper proof, why do you
>> need
>> slow and complex asymmetric encryption again? If you can write protect the
>> kernel,
>> you can also read protect it (or let the boot loader pass the key
Assuming you have a secure kernel binary that is tamper proof, why do you need
slow and complex asymmetric encryption again? If you can write protect the
kernel,
you can also read protect it (or let the boot loader pass the key to the
kernel).
So what stops you from using a simple symmetric key
Assuming you have a secure kernel binary that is tamper proof, why do you need
slow and complex asymmetric encryption again? If you can write protect the
kernel,
you can also read protect it (or let the boot loader pass the key to the
kernel).
So what stops you from using a simple symmetric key
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Assuming you have a secure kernel binary that is tamper proof, why do you
need
slow and complex asymmetric encryption again? If you can write protect the
kernel,
you can also read protect it (or let the boot loader pass the key to the
Indan Zupancic wrote:
Protecting a TripleDES key in high security standards is not as simple as
making the kernel
read protected, you need a whole lot and that also means hardware
(cryptomemories e.t.c)
So you forget about all this overhead when you use assymetric
You need to protect
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Protecting a TripleDES key in high security standards is not as
simple as making the kernel read
protected, you need a whole lot and
that also means hardware (cryptomemories e.t.c)
So you forget about all this overhead when you use
On Wed, March 21, 2007 13:34, Tasos Parisinos wrote:
Indan Zupancic wrote:
Protecting a TripleDES key in high security standards is not as simple as
making the kernel
read protected, you need a whole lot and that also means hardware
(cryptomemories e.t.c)
So you forget about all this
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Protecting a TripleDES key in high security standards is not as
simple as making the kernel read
protected, you need a whole lot and
that also means hardware (cryptomemories e.t.c)
So you forget about all this overhead when you use
On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Protecting a TripleDES key in high security standards is not as
simple as making the kernel read
protected, you need a whole lot and
that also means hardware (cryptomemories e.t.c)
So
Indan Zupancic wrote:
On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
On Wed, March 21, 2007 10:15, Tasos Parisinos wrote:
Protecting a TripleDES key in high security standards is not as
simple as making the kernel read
protected, you need a whole lot and
that also means
on the previous message the exponent is not 32 bits but 64 bits, sorry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Wed, March 21, 2007 15:31, Tasos Parisinos wrote:
Indan Zupancic wrote:
On Wed, March 21, 2007 14:07, Tasos Parisinos wrote:
How can one tamper (write) the kernel memory of a booted and running kernel
without using an exploitable bug?
I mean, you can't mess with the bzImage on flash, the
I agree that you have no more security that using symmetric
but we believe you have lower costs, simpler key management
(which is a big headache alone), tougher to break through
(not unbreakable) and more centralization
It depends a bit on who you want to give control over what can and
On Wed, March 21, 2007 16:50, Tasos Parisinos wrote:
A malicious person may want to alter code on the detachable (and unsafe)
file system.
Lots of stuff including the kernel will be in a trapped casing (opening,
probing it, power
analyzing it, heating it etc will result in system suicide and
If you can't read protect your kernel, you can't write protect it
either.
This is so misleading as to basically be false.
It is true that any security scheme that can prevent people from taking
money out of my account can also prevent people from putting money in.
However, the set of people I
On Tue, March 20, 2007 15:11, Tasos Parisinos wrote:
> Francois Romieu wrote:
>
>> RSA is slow. syscalls are fast.
>>
>> Which part of the kernel is supposed to benefit from this code ?
>
> The main purpose behind the development of this module was to create an
> in-kernel
> system of signed
On Mar 20 2007 10:15, Matt Mackall wrote:
>On Tue, Mar 20, 2007 at 04:44:01PM +0200, Tasos Parisinos wrote:
>> >>+/* Pre-allocate some auxilliary mpis */
>> >>+rsa_echo("Preallocating %lu bytes for auxilliary operands\n",
>> >>+ RSA_AUX_SIZE * RSA_AUX_COUNT * sizeof(_u32));
>> >
Matt Mackall wrote:
[...]
+/* Allocate space for the mpi and its data */
+s = (size / 4) + ((size % 4)? 1: 0);
Uhhh.. (size + 1) / 4?
You mean "(size + 3) / 4", no?
Overall, I agree with your comments: this file looks like it needs a lot
more CodingStyle ;)
Redefining standard
Ok, from what i read, there are many-many similarities in objective but i think
that i take a different aproach in the solution
This is a mod for modular exponentiation only, and this is specific and simple,
cut-down and (as much as possible) overhead free. I don't use gpg structs and /or
other
On Tue, Mar 20, 2007 at 04:44:01PM +0200, Tasos Parisinos wrote:
> >>+/* Pre-allocate some auxilliary mpis */
> >>+rsa_echo("Preallocating %lu bytes for auxilliary operands\n",
> >>+ RSA_AUX_SIZE * RSA_AUX_COUNT * sizeof(_u32));
> >
> >And printk.
>
> i made such a printk wrapper
On Tue, 20 Mar 2007, Tasos Parisinos wrote:
> The main purpose behind the development of this module was to create an
> in-kernel system of signed modules.
I suggest you read this thread:
http://lkml.org/lkml/2007/2/14/164
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list:
Thanks for your comments
On Mon, Mar 19, 2007 at 06:22:15PM +0200, Tasos Parisinos wrote:
+static inline _i32 rsa_max(_i32 x, _i32 y)
+{
+return (x > y)? x: y;
+}
We've got a max() already. Use tabs.
This is right, will be fixed, just hate discipline
+
+/*
+ * Module loading
Francois Romieu wrote:
RSA is slow. syscalls are fast.
Which part of the kernel is supposed to benefit from this code ?
The main purpose behind the development of this module was to create an in-kernel
system of signed modules. The scenario applies most in embedded systems that are running
Francois Romieu wrote:
RSA is slow. syscalls are fast.
Which part of the kernel is supposed to benefit from this code ?
The main purpose behind the development of this module was to create an in-kernel
system of signed modules. The scenario applies most in embedded systems that are running
Thanks for your comments
On Mon, Mar 19, 2007 at 06:22:15PM +0200, Tasos Parisinos wrote:
+static inline _i32 rsa_max(_i32 x, _i32 y)
+{
+return (x y)? x: y;
+}
We've got a max() already. Use tabs.
This is right, will be fixed, just hate discipline
+
+/*
+ * Module loading callback
On Tue, 20 Mar 2007, Tasos Parisinos wrote:
The main purpose behind the development of this module was to create an
in-kernel system of signed modules.
I suggest you read this thread:
http://lkml.org/lkml/2007/2/14/164
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Tue, Mar 20, 2007 at 04:44:01PM +0200, Tasos Parisinos wrote:
+/* Pre-allocate some auxilliary mpis */
+rsa_echo(Preallocating %lu bytes for auxilliary operands\n,
+ RSA_AUX_SIZE * RSA_AUX_COUNT * sizeof(_u32));
And printk.
i made such a printk wrapper not to mess with
Ok, from what i read, there are many-many similarities in objective but i think
that i take a different aproach in the solution
This is a mod for modular exponentiation only, and this is specific and simple,
cut-down and (as much as possible) overhead free. I don't use gpg structs and /or
other
Matt Mackall wrote:
[...]
+/* Allocate space for the mpi and its data */
+s = (size / 4) + ((size % 4)? 1: 0);
Uhhh.. (size + 1) / 4?
You mean (size + 3) / 4, no?
Overall, I agree with your comments: this file looks like it needs a lot
more CodingStyle ;)
Redefining standard
On Mar 20 2007 10:15, Matt Mackall wrote:
On Tue, Mar 20, 2007 at 04:44:01PM +0200, Tasos Parisinos wrote:
+/* Pre-allocate some auxilliary mpis */
+rsa_echo(Preallocating %lu bytes for auxilliary operands\n,
+ RSA_AUX_SIZE * RSA_AUX_COUNT * sizeof(_u32));
And printk.
i
On Tue, March 20, 2007 15:11, Tasos Parisinos wrote:
Francois Romieu wrote:
RSA is slow. syscalls are fast.
Which part of the kernel is supposed to benefit from this code ?
The main purpose behind the development of this module was to create an
in-kernel
system of signed modules. The
Tasos Parisinos <[EMAIL PROTECTED]> :
[...]
RSA is slow. syscalls are fast.
Which part of the kernel is supposed to benefit from this code ?
--
Ueimor
-
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 Mon, Mar 19, 2007 at 06:22:15PM +0200, Tasos Parisinos wrote:
> +static inline _i32 rsa_max(_i32 x, _i32 y)
> +{
> +return (x > y)? x: y;
> +}
We've got a max() already. Use tabs.
> +
> +/*
> + * Module loading callback function
> + *
> + * Returns 0 on success or a negative value
On Mon, 19 Mar 2007 19:22:00 +0200 (EET) Tasos Parisinos wrote:
> As mentioned in the subject this patch applies in kernel version 2.6.20.1.
It needs to apply to Linus's current tree (and it doesn't).
> diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
> linux-2.6.20.1/crypto/Kconfig
From: Tasos Parisinos <[EMAIL PROTECTED]>
This patch changes the crypto/Kconfig and crypto/Makefile and adds
crypto/rsa.c and crypto/rsa.h in the source tree. These files add
module rsa.o (or rsa.ko) in the kernel (built-in or as a kernel module)
and offer an API to do fast modular
From: Tasos Parisinos <[EMAIL PROTECTED]>
This patch changes the crypto/Kconfig and crypto/Makefile and adds
crypto/rsa.c and crypto/rsa.h in the source tree. These files add module
rsa.o (or rsa.ko) in the
kernel (built-in or as a kernel module) and offer an API to do fast
modular
From: Tasos Parisinos [EMAIL PROTECTED]
This patch changes the crypto/Kconfig and crypto/Makefile and adds
crypto/rsa.c and crypto/rsa.h in the source tree. These files add module
rsa.o (or rsa.ko) in the
kernel (built-in or as a kernel module) and offer an API to do fast
modular
From: Tasos Parisinos [EMAIL PROTECTED]
This patch changes the crypto/Kconfig and crypto/Makefile and adds
crypto/rsa.c and crypto/rsa.h in the source tree. These files add
module rsa.o (or rsa.ko) in the kernel (built-in or as a kernel module)
and offer an API to do fast modular
On Mon, 19 Mar 2007 19:22:00 +0200 (EET) Tasos Parisinos wrote:
As mentioned in the subject this patch applies in kernel version 2.6.20.1.
It needs to apply to Linus's current tree (and it doesn't).
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
linux-2.6.20.1/crypto/Kconfig
On Mon, Mar 19, 2007 at 06:22:15PM +0200, Tasos Parisinos wrote:
+static inline _i32 rsa_max(_i32 x, _i32 y)
+{
+return (x y)? x: y;
+}
We've got a max() already. Use tabs.
+
+/*
+ * Module loading callback function
+ *
+ * Returns 0 on success or a negative value indicating error
Tasos Parisinos [EMAIL PROTECTED] :
[...]
RSA is slow. syscalls are fast.
Which part of the kernel is supposed to benefit from this code ?
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
56 matches
Mail list logo
