Different key requires different number of power traces

All power trace values contain noise as well as the power usage for specific data (key) values.
The data (key) values that have a higher power usage are going to stand out more readily from a noisy signal, so will require a smaller number of traces to successfully pinpoint them.

For an analogy think of a bucket of sand (the noise) with a number of different sized rocks in it (the data). If you sift through the bucket with your hands it is easier to find the bigger rocks than the smaller rocks. Though if you keep looking for longer you will eventually find the smaller rocks too.

What causes a particular data (key) value to use more power is device dependent, both on the devices hardware and the implementation of AES (or whatever crypto it uses). It may be due to setting more bits in a byte requiring more power, or a higher number of bits changing bits requiring more power, or any other number of things. So yes this would be related to your devices power model. I imagine if you kept a count of the number of traces required to find data values (key values) then this would give you some info about the power model for your device. Ie if you found that key values of 0xFF were easiest to find, then you might assume that setting more bits uses more power.

I guess it could also be possible that the power usage is basically the same for all keys and you are just sometimes luckier in getting less noise :slight_smile: I am very n00b at this myself, the above is just my take on this from what I have read so far.


There will definitely be some differences in number of traces… this is a real effect! In fact for generating proper graphs/trace stats one should be using a number of different random keys to avoid ‘faking’ the numbers by using either very leaky values or very non-leaky values.

There was a poster at CHES2012 with the title “How to Accelerate Side-Channel Security Evaluation” that showed how to exploit this, the poster title is at cosic.esat.kuleuven.be/ches … osters.pdf but I can’t seem to find a copy unfortunately!