Brumley & Boneh timing attack on OpenSSL (fwd)

Eugen Leitl eugen at
Sat Mar 22 00:51:22 PST 2003

Some clarification by Peter Gutmann <pgut001 at> on why 
cryptlib doesn't do timing attack resistance default:

Peter Gutmann <pgut001 at>:
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
environments, embedded systems and mainframes.  For example two real-world uses
of the cryptlib SSL server are in embedded environment A and mainframe
environment B.

  In A, the processing is handled by a low-power embedded processor.  It takes
  10-15s to perform an SSL handshake, and that's after the code has been
  optimised to death to squeeze every possible bit of performance out of it.
  Performing the necessary 1.5M queries at 15s each would take approximately 8
  1/2 months at 100% CPU load (meaning that the device is unable to perform any
  other operations in that entire time).  This is unlikely to go unnoticed,
  given that it's polled from other devices for status updates.

  In B, CPU resources are so scarce that the implementation uses null cipher
  suites because it can't afford the overhead of even RC4 for encryption
  (admittedly this required a custom code hack, cryptlib doesn't normally
  support null encryption suites).  After about 100 or so attempts at a full
  SSL handshake, klaxons would sound and blue-suited troops would deploy onto
  the raised flooring to determine where all the CPU time is going.

In neither of these environments (and various similar ones) would a side-
channel attack requiring 1M or so queries (e.g. this one, or the Bleichenbacher
attack, or the Klima-Pokorny-Rosa attack, which cryptlib shouldn't be
vulnerable to since I'm paranoid about error reporting) be terribly feasible.
OTOH blinding does produce a noticeable slowdown for a process that's already
regarded by its users as unacceptably slow and/or CPU-intensive (I have some
users who've hacked the key-exchange process to use fixed shared keys because
they just can't spare the CPU time to do a real handshake, e.g. by injecting
the shared key into the SSL session cache so you just do a pseudo-resume for
each new connection).  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

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

More information about the cypherpunks-legacy mailing list