LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tasos Parisinos <t.parisinos@sciensis.com>
To: Indan Zupancic <indan@nul.nu>
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: Wed, 21 Mar 2007 14:34:39 +0200 [thread overview]
Message-ID: <4601265F.4030907@sciensis.com> (raw)
In-Reply-To: <4040.81.207.0.53.1174478934.squirrel@secure.samage.net>
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 your kernel binary already, adding a key to that doesn't increase the
> complexity or safety requirements, so all that hardware safety is already in place.
> (And I'd use AES instead of TripleDES.)
>
>
Well, lets assume you have a trapped casing that prevents a flash chip
(which holds
the kernel) from being tamperred. Then you have write protection of the
bzimage
When this thing will run, and it will need to check an executable using
AES for example
(which is a lot better than TripleDes, i agree) then the key will be for
a time window
onto buses and memory. Then it can be probed and retrieved by someone.
Then you need cryptomemory
While with asymmetric you don't. There are no high-risk data anywhere,
only a public
key
Of course if you have other data that need to be secured, and you
already run
on a trusted platform, including all these crypto hardware modules, then
you can use
a symmetric scheme
Tasos Parisinos
-
next prev parent reply other threads:[~2007-03-21 12:35 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 [this message]
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=4601265F.4030907@sciensis.com \
--to=t.parisinos@sciensis.com \
--cc=herbert@gondor.apana.org.au \
--cc=indan@nul.nu \
--cc=linux-kernel@vger.kernel.org \
--cc=romieu@fr.zoreil.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).