[cryptography] AES side channel attack using a weakness in the Linux scheduler

travis+ml-rbcryptography at subspacefield.org travis+ml-rbcryptography at subspacefield.org
Fri Dec 17 17:49:02 EST 2010


On Sat, Nov 27, 2010 at 08:19:39AM -0800, coderman wrote:
> there are more than a few trivial protections in various
> implementations [not OpenSSL current, per se] that cover usual cache
> line side channels but leaky sieve in branch prediction cache or
> hyper-threading context. and what other esoteric / future cache timing
> attacks to be discovered?

BTW, I have a list of many side-channels here:

http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc31.2

I'll add this one later.

> hardware implementations are (usually) preferable given the broad
> protection provided against entire class of data cache, branch
> prediction, and other CPU / host level cache timing attacks.
> 
> as mentioned previously, this is probably the least of your concerns.
> usability improvement of low latency hw implementations is surely more
> effective rationale than risks of key compromise through local cache
> timing side channel...

Since hyperthreading may not have existed when certain crypto
implementations were written, writing crypto code that's portable
across architectures may expose it to attacks against architectures
which haven't been designed yet, too.

OTOH, hardware tends to be harder to fix or upgrade in the field, and
what is now a hardware accelerator now may become a hardware
deccelerator, depending on CPU performance trends.

Whether would could actually "fix" a fielded cipher in wide software
deployment (say, TLS), given the network effects, is an issue I won't
get into... ;-)
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20101217/13e53284/attachment.asc>


More information about the cryptography mailing list