On 4/13/07, Indan Zupancic <indan@nul.nu> wrote:
quoted text
> 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.

quoted text
> > 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.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/