I dont really get it what exactly block size in openssl speed output means. Here: How can I interpret openssl speed output? I found the answer that it is the length of the input message. So, should I understand like this:

I want to measure performence of md5 for 512 input-size message, should I do it like this:

// assume that 'txt' has a length of 64, 
// so for char its 8 (char size) * 64 (text length) = 512 block size 
char txt = "..."; 
MD5((unsigned char*)&txt, strlen(txt), (unsigned char*)&digest);

or like this:

char txt = "..."; // assume it has length of 512
MD5((unsigned char*)&txt, strlen(txt), (unsigned char*)&digest);

? What Im trying to achieve here is to be able to test algorithms with various input lengths, not only for those defined in openssl speed.

1 Answer 1


A hash function like MD5 processes a message of arbitrary length (up to some ludicrously large maximum length, some zillions of terabytes). The raw computational cost of MD5 can be roughly split into three parts:

  • Initialization: set some internal state values.
  • Data processing: mostly proportional to the input length.
  • Finalization: the "closing computations" of the hash function, yielding the final output (things like padding occur at that step).

OpenSSL, in its benchmarks, measures the speed of doing the three steps with messages of various lengths, so that you might somehow infer the cost of the data processing and the cost of the two other steps.

However, such benchmarks are meaningless because they measure the code performance under unrealistic conditions. When OpenSSL runs, it goes into a tight loop, hashing millions of messages in a row: this ensures that the hash function code itself is in L1 cache, that branch prediction in the CPU is fully aware of the probable direction of each conditional jump, and that the input data is also in the CPU L1 cache. None of this really applies to a practical situation.

In practice, I/O and RAM bandwidth costs will dominate, especially with "fast" hash functions like MD5; also, the hash function is not alone in the data path, and other tasks will matter. For instance, in your code, the call to strlen() will not have a negligible impact when compared with MD5 (it will be faster, but not to the point of not even showing up in measures).

What you should do is to measure performance of your complete system, not the hash function alone; and do that with a few select hash functions: this will use the actual execution context. Also, it is improbable that the hashing cost itself represents a substantial proportion of your CPU.

  • Thanks, it makes sense now. So openssl's benchmark is meaningless too? What is the best way to benchmark a cryptographic algorithm? Could you give some samples, for example in pseudocode? Cheers:)
    – yak
    Jul 16, 2013 at 16:00
  • 1
    All microbenchmarks are meaningless -- or at least have little meaning. A microbenchmark concentrates on a specific element (e.g. a hash function). You can measure its speed in ideal condition (you must account for some "warm-up" so that caches are filled and so on, and measure for several seconds at least in a tight look) but it won't tell you much about actual performance once put in practical conditions, because practical conditions are never ideal.
    – Tom Leek
    Jul 16, 2013 at 16:12
  • 1
    Best way to benchmark algorithms is to do it later. Performance issues should be taken care of only after having been encountered and duly measured in a reasonably complete system. "Premature optimization is the root of all evil" (so says Donald Knuth).
    – Tom Leek
    Jul 16, 2013 at 16:15
  • Can I ask you just one more question? You wrote that When OpenSSL runs, it goes into a tight loop, hashing millions of messages in a row isn't it a "warm-up" you mentioned about in your comment? Or how should I understand such "warm-up"? cheers
    – yak
    Jul 16, 2013 at 18:19
  • 1
    "Warm-up" is about running the loop a few dozen times before actually timing the loop execution. You might want to have a look at this library which includes implementations of hash function, and some benchmark code which times them (in "ideal conditions"). The benchmark code will show you how these things are done (the Java version is easier to read than the C version).
    – Tom Leek
    Jul 16, 2013 at 18:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .