On Wed, Apr 07, 2010 at 06:58:05PM +0100, David Woodhouse wrote:
> As you can see, the results all got much faster once I got back in time
> to about mid-2007. Using 'git-bisect' I was able to find the offending
> commit which had caused the performance degradation:
> http://git.infradead.org/users/dwmw2/openssl-parsecvs.git/commitdiff/25e9f96b
That would be:
http://cvs.openssl.org/chngview?cn=16371
Likely this is in part intended to address timing attacks. At first
glance, the assembly code seems to have two implementations of AES, a fast
one and a slow one, and some code at the top to choose between them. There
is also a magic number (512 I think) that I am guessing selects the fast
path for blocks of 512 bytes and up and the slow path for smaller blocks.
Can someone confirm that what we are seeing is a work-around for DJB's
cache timing attack on AES? If so, I would guess that the timing attack
is believed to be impractical for large blocks, so the fast path is used
only for sufficiently large inputs...
Are there sound estimates of how quickly the timing signal degrades with
the input size? How conservative is the 512-byte cutoff
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
