LKML Archive on
help / color / mirror / Atom feed
From: "Indan Zupancic" <>
Cc: "Linux-Kernel@Vger. Kernel. Org" <>
Subject: RE: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel  version
Date: Thu, 22 Mar 2007 14:15:58 +0100 (CET)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

(Please don't trim me from the CC list if you're replying to what I've said,

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 don't see how you'd achieve it.
Looks more like a misunderstanding than misleading going on here.

> 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 allow to put money in my account might include
> people I don't want to be able to take money out.

I wasn't talking about a single security scheme, I was talking about the
possible schemes. Would you trust someone to protect your account if he says
he's able to write protect your account, but not read protect it? And keep
in mind I'm talking about technical abilities, not cases where one access
is chosen to be allowed.

Purposely allowing the one and disallowing the other is a different case.
But there's a difference between opening your door and having a door with
a bad lock.

> As a more concrete counter-example, consider a signed kernel module that I
> wish to publically distribute. I can't stop anyone from reading it. I can
> certainly keep people from changing the copy running on my machine.

Maybe, maybe not. The signature won't stop people from modifying the loaded
kernel, something else has to. And if that 'something' can stop modifications,
it most likely can also read protect a part of kernel RAM too, with little
tweaking. If it can't, I wouldn't trust it to write protect the kernel either.

> Your point is not even valid about keys residing in RAM. There are perfectly
> sensible scenarios in which the same key needs to be in several different
> places, some very secure, some not so. Using a symettric key means that the
> securest use can be compromised by a break of the least-secure use. Consider
> data that is signed by the kernel and verified by a user-space program.

My point is valid, but you seem to confuse it with scenarios where you want to
allow the one and disallow the other, and using that as an argument that my
point isn't valid.

I already said in another email that symmetric key encryption is only as secure
as RSA if each device has its own key, in the case of signed binaries. I'm also
not trying to argue that all asymmetric crypto uses can be replaced with
symmetric ones, in case you wonder.

What I do try to make clear is that for certain cases there are alternatives
which are as secure as RSA, and that a lot apparent weaknesses of that approach
are also present with RSA, and that no matter what you use, you need to have
the same basic security in place for both.



  reply	other threads:[~2007-03-22 13:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-19 16:22 Tasos Parisinos
2007-03-19 22:58 ` Matt Mackall
2007-03-20 14:44   ` Tasos Parisinos
2007-03-20 15:15     ` Matt Mackall
2007-03-20 16:36       ` Jan Engelhardt
2007-03-20 15:43   ` Paulo Marques
2007-03-20  0:40 ` Francois Romieu
2007-03-20 14:11   ` Tasos Parisinos
2007-03-20 15:09     ` James Morris
2007-03-20 15:40       ` Tasos Parisinos
2007-03-20 21:43     ` Indan Zupancic
2007-03-21  9:15       ` Tasos Parisinos
2007-03-21 12:08         ` Indan Zupancic
2007-03-21 12:34           ` Tasos Parisinos
2007-03-21 13:00             ` Indan Zupancic
2007-03-21 23:31           ` David Schwartz
2007-03-22 13:15             ` Indan Zupancic [this message]
2007-03-21 12:36         ` Indan Zupancic
2007-03-21 13:07           ` Tasos Parisinos
2007-03-21 13:59             ` Indan Zupancic
2007-03-21 14:31               ` Tasos Parisinos
2007-03-21 15:10                 ` Indan Zupancic
2007-03-21 15:50                   ` Tasos Parisinos
2007-03-21 16:36                     ` Indan Zupancic
2007-03-22  7:47                       ` Tasos Parisinos
2007-03-21 14:49               ` Tasos Parisinos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='RE: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel  version' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).