linux-kernel - Re: [PATCH resend][CRYPTO]: RSA algorithm patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Apr 2007 02:43:05 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Indan Zupancic" <indan@....nu>
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 4/13/07, Indan Zupancic <indan@....nu> wrote:
> On Thu, April 12, 2007 21:57, Satyam Sharma wrote:
> > Of course, I'd rather code to the PKCS#1 RSA Cryptography Standard
> > than an entry-level Wikipedia page :-) Timing attacks are particularly
> > problematic on smart cards (too slow, and with predictable operation
> > times, if not using constant-time crypto implementations) and not
> > really worthwhile in practice on any other platform where there's
> > enough noise around to make accurate timing difficult
>
> Noise can be filtered out, and combined attacks can give enough information.
> (E.g. throw in power usage or other measurements.) There are ways to add
> noise to the timing, but still using those optimisations. The point was
> that they add extra code and complexity.
>
> (Personally I think RSA-like asymmetric encryption has so many, often
> subtle problems, with complex, hard to get secure implementations, that
> it's something I'd avoid using as much as possible. Unfortunately there's
> not much alternative.)

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.

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.

> > 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.
-
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/