How can I analyze a cryptographic algorithm performance to make a table and charts comparing them. I have seen several papers but there's no paper explaining how it is exactly done.
As comparing data block size through time, etc...
Like key size, block size, power, throughtput, data length, processed bytes (MiB/s) and cycles per byte.
Example papers:
It is not given because it is assumed that you either know it anyway, if you deal with cryptographic algorithms, or you don't need it, because its complex and time consuming and only a few people in the world need it, and can properly read the result.
To test throughput (Mb/sec, same as processed data) you need a fast device to write to, usually hdd itself adds too much delay to measure this correctly. You could use ram filesystem for it, and write there. You didn't mention the OS, so I will assume linux. You write a big file and measure the time it took
Knowing how big the file you've made and how much time it have taken, you can calculate the throughput, dividing file size by time taken. You could use writing to /dev/null, but its hard to predict how much optimization OS will do, so I would offer to avoid this.
Key size is given in algorithm initialization, you cant start without giving this information. If Crypto++ hides this information from you, try to search for something else. Or look for default values. For AES its 16 bytes.
Same for block size. Same link shows that block size is 16 bytes for AES too. As with the previous case you set it up yourself, and many algorithms accept different versions of key size and block size. Those are given at the start by the user. Or are defaults, that can be found about the particular implementation, algorithm + program that make it work.
Power is hard to estimate because efficiency of devices differ dramatically. Even if you measure it for your device, it will be different for another device. Simplest way is to write a large file in RAM, delete it, write again, in a loop for hours till your laptop battery drains out. Then check how big your battery was.
Or try checking the power consumption of your flat on a power meter, but this is even less precise. Proper method would use something like this
You could get a bit more precise result if you compare idle operating computer with computer that is doing your task. This way you automatically exclude all the parts that are not working for the cryptographic task, like a screen.
The cycles per byte is the most complex part. For this you actually need to read the code and see how many operations are done from start to finish, and then divide this amount of operations by the size of an output. If an algorithm took 17 operations like addition, xor and multiplication, and a device can do all of them in in one clock time, and output is 4 byte long, then the result is 17/4=4.25 cycles per byte. Keep in mind that modern CPU can operate on a very large words, 128bit (16byte), and that some operations can take a very long time, like exponentiation, that can take a 100 operations. You need to find the cost of each operation on a given machine. Usually it is 1 for addition, bit operations, multiplication, about 10 for division, sqrt, 100 for more complex operations like exponentiation, trigonometric functions for a modern CPU. Microcontrollers may only have fast addition. GPU may have fast division, but not bit operations. By fast I mean one cycle operation. So that in one clock step it will make one action like addition.
You may also be interested in checking how strong an algorithm is. This is done by reducing the key size and using a program that analyses the patterns in the output, TestU01 for example. Here is my favorite work on this topic, I like it for simplicity and visualisations mostly:
And this website in general. It allows to see how the cryptographic people think in general, what tools they use, what they value in an algorithm.
TLDR: you are asking about a lifetime worth of time spent collecting tools needed for a very complex task. I cant give you all of them. And there is no ready solution. Very few people need this.
The results of our implementations appear in Table 2. A$\endgroup$