LKML Archive on
help / color / mirror / Atom feed
From: "Tasos Parisinos" <>
To: "Francois Romieu" <>
Cc: <>, <>
Subject: Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel version
Date: Tue, 20 Mar 2007 16:11:11 +0200	[thread overview]
Message-ID: <000601c76af9$a0ce3ce0$0864a8c0@scs1> (raw)
In-Reply-To: <>

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.

In such systems we need to detect the tampering in a centralized way (e.g without using hash databases e.t.c). 
So what you need to do is sign the executable (or the library) with a private key and have a kernel that will 
use the public key part to authenticate the executable againts its digital signature.

Of course the signing and the authentication is not done against the whole executable but against its 
secure hash, and this takes milliseconds to complete before loading the code onto memory.
You see, in such a usage scenario most of the time the kernel will spend will be on hashing (sha1 module) and not in 
modular exponentiation. Of course this will not produce any soft lockups

Such a system cannot depend on userland to do the authentication for obvious security reasons, it 
must be in kernel.

Of course sha1 is slow as well but there is an sha1 module for anyone who may need it.
That was my idea, we developed it for our own security needs, why not make it available for
others that may want to use it?

Furthermore one can use the API to do multi-precision arithmetics, if any kernel module may need it

Tasos Parisinos

  reply	other threads:[~2007-03-20 14:41 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 [this message]
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
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 \
    --in-reply-to='000601c76af9$a0ce3ce0$0864a8c0@scs1' \ \ \ \ \
    --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).