Cache-timing attack

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Cache-timing attack

Eric Murray

Are there any plans to address Daniel J. Bernstein's
Cache-timing attack on Openssl's AES implementation?

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf


Eric


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cache-timing attack

Andy Polyakov
> Are there any plans to address Daniel J. Bernstein's
> Cache-timing attack on Openssl's AES implementation?

First of all keep in mind that formally one should say "attack on high
performance AES implementations.";-)

> http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

It's impossible to address this attack [without sacrificing a *lot* of
performance], only *mitigate* the impact. As of now, we mitigate the
impact *only*

- on x86 architecture;
- in CBC mode;
- in 0.9.8 and development branch;

On can argue why just/only CBC? Because it's most commonly/widely used
mode and because it's possible to maintain virtually same performance
[at least for larger chunks] without modifying our API. If any other
mode is of interest to "protect," then it's more likely to be counter
and CCM modes, rather than ECB [the one seldomly used, but discussed in
the referred paper].

As for other architectures, it's on "as time permits" basis. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cache-timing attack

Eric Murray
On Mon, Jun 20, 2005 at 07:09:29PM +0200, Andy Polyakov wrote:
> > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
>
> It's impossible to address this attack [without sacrificing a *lot* of
> performance], only *mitigate* the impact. As of now, we mitigate the
> impact *only*
>
> - on x86 architecture;
> - in CBC mode;
> - in 0.9.8 and development branch;

Is that in crypto/aes/asm/aes-586.pl:

# Version 3.3 avoids L1 cache aliasing between stack frame and
# S-boxes, and 3.4 - L1 cache aliasing even between key schedule. The
# latter is achieved by copying the key schedule to controlled place in
# stack. This unfortunately has rather strong impact on small block CBC
# performance, ~2x deterioration on 16-byte block if compared to 3.3.

Is there a way I can select between version 3.4 and 3.3 to regain
small block performance if I address the timing issue at a higher level?


Thanks.

Eric

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cache-timing attack

Andy Polyakov
>>>http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
>>
>>It's impossible to address this attack [without sacrificing a *lot* of
>>performance], only *mitigate* the impact. As of now, we mitigate the
>>impact *only*
>>
>>- on x86 architecture;
>>- in CBC mode;
>>- in 0.9.8 and development branch;
>
>
> Is that in crypto/aes/asm/aes-586.pl:
>
> # Version 3.3 avoids L1 cache aliasing between stack frame and
> # S-boxes, and 3.4 - L1 cache aliasing even between key schedule. The
> # latter is achieved by copying the key schedule to controlled place in
> # stack. This unfortunately has rather strong impact on small block CBC
> # performance, ~2x deterioration on 16-byte block if compared to 3.3.
>
> Is there a way I can select between version 3.4 and 3.3 to regain
> small block performance if I address the timing issue at a higher level?

How do you "address timing issue at higher level"? You probably mean
"*aliasing* issue at higher level." If so, then to answer the question
I'd say it's pretty much definition of "too much to ask":-) Indeed, if I
tell you how to pull previous version from CVS, then I impicitly take
responsibility for maintaining it. And I don't want that. Nor do I want
to tell how to tweak internal script parameters [such as $compromise] in
aes-586.pl for same reason. Latest version with unchanged internal
parameters is what we stand for, period. Anything else are your own
deeds and resposibility:-) What's appropriate to discuss is to modify
the latest version so that it *detects* if there is aliasing and copy
key schedule only if there is one detected. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]