Jack Lloyd lloyd at
Tue Jan 3 18:01:07 EST 2006

On Tue, Jan 03, 2006 at 10:10:50PM +0000, Ben Laurie wrote:

> Yes, you are - there's the cache attack, which requires the attacker to
> have an account on the same machine. I guess I shouldn't have called it
> constant time, since its really constant memory access that defends
> against this.

Thanks for the link! Does OpenSSL defend against this attack? I suspect writing
fast modexp code that will (in the paper's words) "avoid any data-dependent or
key-dependent memory access or code path patterns" would be quite non-trivial,
so I would be interested to see how that is implemented. I did a quick scan
through 0.9.8a's crypto/bn but didn't see anything that looked likely, but
OpenSSL is big, so I could easily be missing it. :)

> Incidentally, I think the main component of the difference on Athlon,
> like many other platforms, is simply a question of which library has
> hand-optimised assembler for the platform. That is, it tells us little
> about architectural differences and plenty about whether anyone has been
> bothered to optimise for that particular platform recently.

That's an good point - probably compiling both OpenSSL and GNU MP with no
assembly code would be a more interesting comparison, from an algorithm

However, I think you are confusing two different goals here. I'm guessing that
you want an analysis of GNU MP vs OpenSSL so you can figure out how to make
OpenSSL faster. For that, an algorithm-based analysis is obviously much more
useful. I mostly care about which is faster, now, on the platforms I care
about, and it doesn't really matter why one is faster. For example, if GNU MP
has a faster modexp implementation than OpenSSL on an Athlon because the GNU MP
developers sold their souls to the devil [*] in exchange for some really good
hand-tuned Athlon asm, that's cool with me -- as long as it's fast.


[*] I make no claims that the GNU MP developers have actually been involved in
    any unholy bargains involving souls for code.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list