You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to use your framework to assert that a function is constant-time. The goal of this PR is not to add something new into this repository but to have some explanation - may be, I misunderstand something. Here we have a "constant-time" memcmp function (available here) and I tried to run your framework on it.
However, with dudect_simple_O0, I reached the point where the program tell me:
Probably not constant time
The max_t increases even if this function should be in constant-time.
The situation differs when we increase the number of samples with MEASUREMENTS_PER_CHUNK. In this situation, even memcmp never reaches the Probably not constant time. By this way, I can not really reproduce what you were saying in our paper locally - I currently test that on a bare-metal server, an Intel Xeon CPU D-1531 @ 2.20Ghz.
May be I do something wrong or I misinterpret results 😕 . Thanks!
it's aeons since I last had a look at these kinds of issues. I suggest several paths to debug this kind of issues:
open the binary with objdump / IDA and try to make sense of it. check carefully if the compiler / linker is rearranging the order of execution of different functions. an optimizing compiler could re-arrange the execution of different blocks without affecting the input/output behavior, but with very significant changes to the measured execution time. in particular, I'd suggest staring at the disassembly and make sure the chunk between RDTSC instructions corresponds to the function you want to measure. maybe we're not measuring what we want to measure 🙂.
try to progressively simplify the function that should be constant time but it's reported to not be, measure every step of the simplification and see if you get different results. the simplified function may no longer compute the correct value, but that doesn't matter for this purpose. cross check this with the disassembler dump. similarly, add some blatant non-constant time chunks if a function is expected to leak, but you can't detect it
check there's no compiler-time/linking-time optimization magic messing up measurements. in hindsight, distributing dudect as a single header file isn't a great idea to make this unlikely to happen. probably separating the function under test from the measurement function in a different translation unit will make it harder for the compiler to optimize (make sure to disable LTO).
The situation differs when we increase the number of samples with MEASUREMENTS_PER_CHUNK.
My gut feeling for the different behavior when varying MEASUREMENTS_PER_CHUNK is that the compiler emits different code if that constant is small vs big (unrolling / ...). Maybe dump the binary and check if there're significant differences?
In this situation, even memcmp never reaches the Probably not constant time
I'd suggest exaggerating the intended leakage: can you make the two classes more dissimilar? for example, increasing the buffer length that memcmp checks, so that when the input to memcmp are two identical buffers, it takes a long time to compare them.
Hope you can have some quality time with your compiler, CPU and disassembler. Good luck! 🍀
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
I tried to use your framework to assert that a function is constant-time. The goal of this PR is not to add something new into this repository but to have some explanation - may be, I misunderstand something. Here we have a "constant-time"
memcmpfunction (available here) and I tried to run your framework on it.However, with
dudect_simple_O0, I reached the point where the program tell me:The situation differs when we increase the number of samples with
MEASUREMENTS_PER_CHUNK. In this situation, evenmemcmpnever reaches theProbably not constant time. By this way, I can not really reproduce what you were saying in our paper locally - I currently test that on a bare-metal server, an Intel Xeon CPU D-1531 @ 2.20Ghz.May be I do something wrong or I misinterpret results 😕 . Thanks!