[Cryptography] Computing the speed of a cipher or hash

Jerry Leichter leichter at lrw.com
Mon Aug 25 17:40:28 EDT 2025


> Speeds of ciphers and hash functions are expressed in cycles per byte. I can 
> measure the time it takes to process many bytes with the @time macro, but how 
> do I convert that to cycles? I can look at /proc/cpuinfo while the code is 
> running, but it shows that some cores are running much faster than others, and 
> the clock speed varies....
The notion of "cycles" as some kind of invariant measure for a modern CPU is essentially meaningless.  Besides various internal complexities what with multiple units and caches and such, all modern CPU's are capable of adjusting their speeds in response to load and, particularly, temperature.  Many CPU's are able to run bursts at (sometimes significantly higher) clock speeds, but they can only keep that up for a little while before they get too hot and have to back off.  This would produce very different numbers for "small" vs. "large" inputs.

As far as I can tell, any cycles/byte rating of code for a modern CPU is either (a) actually for some fictional CPU where we count one cycle per "simple" instruction, like XOR or addition, and avoid "complex" instructions, which you'd expect any modern cipher or hash function to do anyway; (b) based on some kind of measurement that relies on, e.g., /proc/info - which really doesn't mean anything except in the _exact_ scenario under which it was obtained.

In practice, (a) above is reasonable if your purpose is to compare different algorithms and their implementations, because the model isn't that far off from the performance that modern machines can provide - as long as you don't take the number too literally.  (Of course, if you have something like an algorithm that relies on lookups in a large table, the _actual_ performance will likely be dominated by cache/memory access effects, which won't show up in any simple model.  But no one with any experience would suggest such an algorithm today.)

                                                        -- Jerry



More information about the cryptography mailing list