Not able to get the results similar to the one mentioned in Readme

[iaik]

Not able to get the results similar to the one mentioned in Readme

[dgruss]

maybe a different library version, then the arrays might have different offsets or even have been moved to different .so files... i would start with only a few keys first, that's faster and as soon as that works try other keys as well...

also: make sure that gedit has the focus and that keys are actually sent to the target window throughout the whole attack... and that you used the correct cache hit/miss threshold for your system... if some part here goes wrong the attack can't work at all.

[agarwalayush]

Yes I always made sure that gedit was the target window.
First I tried with all the keys but only on a specific library which you have mentioned in the paper /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1000.8.
Then I tried with few specific keys mnopq and increased duration (400) but still not good results.

And also, Currently I am using ubuntu's default window manager which has around 26 instances of libgdk-3 in the memory. Can that create a significant amount of noise?

[agarwalayush]

The calibration script's results are not very consistent. I mean sometimes I got 125 and sometimes 210. I guess the way of calculating the threshold may be improved by using the weighted average?

[dgruss]

i got my results from linux machines with xubuntu default installations
and several programs running...
maybe the threshold is not configured correctly?

[dgruss]

it is necessary to look at the histogram by hand, noise is easily introduced - the suggested threshold is computed in a very simple way, often works, but if it doesn't you need to check the histogram... if you have a few cases with low access times where a cache miss is expected, you might just ignore these few cases and be ok with a potentially slightly higher false positive rate... find the lowest access time for a cache miss (ignore noisy cases if the counts are low enough). then subtract maybe 30-40 cycles from that (reason is that you want to ignore cache misses that are dram row hits cf. https://github.com/IAIK/drama). that should be the best threshold for your system. and check that this is consistent, if the histogram already varies significantly, then there might be something weird with your system. maybe the CPU is lacking some feature like constant_tsc, then for instance rdtsc can't be used for the timing measurement and you have to use clock_gettime() instead...