Brumley & Boneh timing attack on OpenSSL (fwd)

Bill Stewart bill.stewart at pobox.com
Sat Mar 22 12:25:58 PST 2003


At 09:51 AM 03/22/2003 +0100, Eugen Leitl wrote:
>Some clarification by Peter Gutmann <pgut001 at cs.auckland.ac.nz> on why
>cryptlib doesn't do timing attack resistance default:
>
>Peter Gutmann <pgut001 at cs.auckland.ac.nz>:
>cryptlib was never intended to be a high-performance SSL server (the docs are
>fairly clear on this), and I don't think anyone is using it to replace Apache
>or IIS.  OTOH it is used in a number of specialised environments such as 
>closed
...
>  For this reason, cryptlib makes the use of sidechannel-
>attack-protection an optional item, which must be selected by the user 
>(via use
>of the blinding code, now admittedly I should probably make this a bit easier
>to do in future releases than having to hack the source :-).  This is not to
>downplay the seriousness of the attack, merely to say that in some cases the
>slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend
>against.

If it's not meant to be a high-performance server, then slowing it down
another 20% by doing RSA timing things is probably fine for most uses,
and either using compiler flags or (better) friendlier options of some sort
to turn off the timing resistance is probably the better choice.

I'm not sure how flexible things need to be - real applications of the
openssl code include non-server things like certificate generation,
and probably some reasonable fraction of the RSA or DH calculations
don't need to be timing-protected, but many of them are also things
that aren't CPU-consumption-critical either.




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com





More information about the cypherpunks-legacy mailing list