LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Indan Zupancic" <indan@nul.nu>
To: "Tasos Parisinos" <t.parisinos@sciensis.com>
Cc: "Francois Romieu" <romieu@fr.zoreil.com>,
	herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel  version 2.6.20.1)
Date: Tue, 20 Mar 2007 22:43:30 +0100 (CET)	[thread overview]
Message-ID: <4734.81.207.0.53.1174427010.squirrel@secure.samage.net> (raw)
In-Reply-To: <000601c76af9$a0ce3ce0$0864a8c0@scs1>

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 scenario applies most in embedded systems that are running linux
> where the kernel is physically secure but its filesystem is not, so one may tamper executable
> code.

I'll summarize/rephrase what I've already said in the thread James Morris linked to:

You need a way to protect your kernel binary, or else this whole thing becomes a joke.
(Modify kernel, reboot...)

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 cipher for signing?

Regards,

Indan



  parent reply	other threads:[~2007-03-20 21:43 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 [this message]
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
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=4734.81.207.0.53.1174427010.squirrel@secure.samage.net \
    --to=indan@nul.nu \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=romieu@fr.zoreil.com \
    --cc=t.parisinos@sciensis.com \
    --subject='Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel  version 2.6.20.1)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).