Message-ID: <1920.81.207.0.53.1176418265.squirrel@secure.samage.net>
Date:	Fri, 13 Apr 2007 00:51:05 +0200 (CEST)
From:	"Indan Zupancic" <indan@....nu>
To:	"Satyam Sharma" <satyam.sharma@...il.com>
Cc:	"Tasos Parisinos" <t.parisinos@...ensis.com>,
	"Bill Davidsen" <davidsen@....com>,
	"Andi Kleen" <andi@...stfloor.org>, herbert@...dor.apana.org.au,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com
Subject: Re: [PATCH resend][CRYPTO]: RSA algorithm patch

On Thu, April 12, 2007 23:13, Satyam Sharma wrote:
> But timing attacks are not exclusive to RSA / asymmetric
> cryptosystems. Such (side channel / timing / power measurement / bus
> access) attacks are possible against AES, etc too.

True, but those are often easier to protect, or are less vulnerable in
the first place. (E.g. it isn't very hard to make a constant time AES
implementation. The operations it does are independent of the key.)


> Of course, now we're really moving into a different realm -- I guess
> in security there is always a threshold, and you really needn't care
> beyond a particular threat perception level. I don't see how even the
> existing cryptoapi (or *any* security measure in the kernel for that
> matter) stands up to the kind of attacks we're talking about now.

True, and very specialized hardware is needed in such cases anyway, so
arguing that it's not the kernel's task to protect against such attacks
is valid. But it are interesting attacks, and people should be aware of
them, instead of blindly trusting any security measure (not implying
anyone here does, I mean in general).


>> > constant-time crypto implementations do take care of
>> > them, though I agree the GPG code too lacks that.
>>
>> That's because for side-channel attacks you need physical access to the
>> hardware, something for most machines means security is breached anyway.
>> But when this code is going to be used to sign things by embedded devices
>> (with a local, secret key), it can be important.
>>
>> For checking signatures the key is known and all this doesn't matter, but
>> we're talking about a common implementation. It are things to keep in mind.
>
> I think the original idea was to generate signatures at a centralized
> place (not on an embedded system) and only *verify* them using
> *public* keys on the embedded systems? For most common
> implementations, as I suggested, you only need bother yourself upto a
> certain security threshold.

Yes, but it depends on how the code is used. It is supposed to be generic code,
so whether someone wants to use it for signing or not is an open question. So
far it seems only signature checking is needed, and that simplifies a lot, but
if that isn't the case more questions pop up, like where the security threshold
should be.

The user with the tightest requirements more or less dictates the implementation.

All in all, to get anything merged at all in the kernel it seems at least the
following needs to happen:

- Future users speaking up and uniting.

- Figuring out their needs (so overlapping needs can make it into common
  code, and other decisions can be made, as where the kernel and user
  space border should be.)

- Deciding on a commonly agreed security threshold, and making that explicit.

- Coding it all up and keeping it in sync with mainline.

I don't see this happening soon. But a good start would be if someone who
cares about this sets up a mailing list or website to collect all users
and information.

Good night,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists