public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tasos Parisinos <t.parisinos@sciensis.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
	randy.dunlap@oracle.com, indan@nul.nu
Subject: Re: [PATCH resend][CRYPTO]: RSA algorithm patch
Date: Mon, 02 Apr 2007 14:50:17 +0300	[thread overview]
Message-ID: <4610EDF9.9000601@sciensis.com> (raw)
In-Reply-To: <p73r6r3yn9f.fsf@bingen.suse.de>

Andi Kleen wrote:
> Tasos Parisinos <parisino@ceid.upatras.gr> writes:
>
>   
>> From: Tasos Parisinos <t.parisinos@sciensis.com>
>>
>> This patch adds module rsa.ko in the kernel (built-in or as a kernel
>> module) and offers an API to do fast modular exponentiation, using the
>> Montgomery algorithm, thus the exponentiation is not generic but can
>> be used only when
>> the modulus is odd, such as RSA public/private key pairs. This module is the
>> computational core (using multiple precision integer arithmetics) and does not
>> provide any means to do key management, implement padding schemas e.t.c. so the
>> calling code should implement all those as needed. Signed-off-by:
>> Tasos Parisinos <t.parisinos@sciensis.com>
>>     
>
> You forgot to answer the most important question.
>
> What would want to use RSA in the kernel and why?  
>
> -Andi
>
>   

The main purpose behind the creation of this module was to create the
cryptographic infrastructure to develop an in-kernel system of signed
modules.

The best environment to deploy such functionality is in updating by remote,
executable code (programs, libs and modules) on embedded devices running
Linux, that have some form of kernel physical security, so one can't 
tamper the
kernel, but can read it. In this case only a public key would be 
revealed. The
vendor of the devices can sign and distribute/update executable code to 
the devices,
and the kernel will not load/run any of them if they don't match with 
their signatures.
The signature can be embedded in the elf, so this system is portable and 
centralized.
Although this functionality can be achieved using userland helper 
programs this may
create the need to physically secure entire filesystems which adds to 
the cost of
developing such devices. In such cases one needs to use asymmetric 
cryptography
because in the case of symmetric it would be very easy to give away the 
key and
end with having all your devices being attacked.

There are already some systems that implement and utilize such 
functionality that
use windows platforms, and other Linux distros that use userland 
programs to do
so, assuming physical security of the host computer.

Moreover a same system that would use hashes is easier to brake and more 
difficult
to update each time new code must be loaded to the host devices.

See also this thread

http://lkml.org/lkml/2007/3/19/447




  reply	other threads:[~2007-04-02 11:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-02  9:52 [PATCH resend][CRYPTO]: RSA algorithm patch Tasos Parisinos
2007-04-02 12:27 ` Andi Kleen
2007-04-02 11:50   ` Tasos Parisinos [this message]
2007-04-02 13:28     ` Andi Kleen
2007-04-02 15:10       ` Tasos Parisinos
2007-04-02 15:28         ` Andi Kleen
2007-04-03 16:03         ` Pavel Machek
2007-04-04  9:55           ` Tasos Parisinos
2007-04-04 12:01             ` Pavel Machek
2007-04-06 21:30     ` Bill Davidsen
2007-04-06 23:06       ` Indan Zupancic
2007-04-07  3:53         ` Bill Davidsen
2007-04-11 10:14           ` Tasos Parisinos
2007-04-11 14:37             ` Indan Zupancic
2007-04-12  8:34               ` Tasos Parisinos
2007-04-12  9:35                 ` Satyam Sharma
2007-04-12 12:22                   ` Indan Zupancic
2007-04-12 12:40                     ` Andi Kleen
2007-04-12 14:20                     ` Satyam Sharma
2007-04-12 15:01                       ` Indan Zupancic
2007-04-12 18:38                         ` Satyam Sharma
2007-04-12 19:05                           ` Indan Zupancic
2007-04-12 19:57                             ` Satyam Sharma
2007-04-12 20:44                               ` Indan Zupancic
2007-04-12 21:13                                 ` Satyam Sharma
2007-04-12 22:51                                   ` Indan Zupancic
2007-04-12 21:28                     ` David Wagner
2007-04-12 23:31                       ` Indan Zupancic
2007-04-13 13:56                         ` Tasos Parisinos
2007-04-12 13:09                 ` Indan Zupancic

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=4610EDF9.9000601@sciensis.com \
    --to=t.parisinos@sciensis.com \
    --cc=andi@firstfloor.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=indan@nul.nu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox