[Cryptography] Computing the speed of a cipher or hash

[Pierre Abbat]

On Monday, August 25, 2025 5:40:28 PM EDT Jerry Leichter wrote:
> 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.

I found the cpucycle function, which does the rtdsc instruction, and measured 
cycles per byte on two different processors, using a 16-byte key and ten 
million bytes of plaintext.

AMD Ryzen 5 3600X: 1056-1075

Intel Core i9: 211-213

> 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.)

Daphne uses two different multiplications and an S-box, which it does 33 times 
for every byte if the key is 16 bytes (except that when decrypting, the last 
one is two different divisions and the inverse S-box). The S-box is kept in a 
256-byte table. I tried multiplication functions versus a 65536-byte table and 
found that the table is faster. But when I tried putting the whole operation, 
which has three inputs, into a 16,777,216-byte table, that made it slower.

Pierre

-- 
ve ka'a ro klaji la .romas. se jmaji