oreparaz / dudect Goto Github PK

We could do some sanity checks to make sure we're not catching (statistical) ghosts:

• statistical test on a random partition of one group (all corresponding to the same input). should not yield any statistical difference
• idem, for the second group
• idem, for a random partition of the set of all traces.

These tests should all return "no leakage detected". I'd say this isn't super high priority, please check-in here before if you're interested in working on this.

Add some tests for the Welch T-test code, possibly testing it against another implementation.

Maybe easiest is to use golang:

• https://pkg.go.dev/golang.org/x/perf/internal/stats#TwoSampleWelchTTest
• looks minimally tested https://cs.opensource.google/go/x/perf/+/1a17dc26:internal/stats/ttest_test.go;bpv=1;bpt=0

Pornin says here https://github.com/pornin/crrl#benchmarks:

If frequency scaling ("TurboBoost") is not disabled, then you'll get wrong and meaningless results.

The way dudect is designed is meant to provide some degree of protection against bogus data (since we're interleaving measurements); yet, bad data is obv a bad idea and can provide a false sense of security.

We should detect and warn if frequency scaling is enabled on dudect_init(). TBD how to do this, suggestions welcome as comments here. We should strive to be as helpful as we can: in addition to warning the human, we should provide instructions / links on how to disable it.

@itzmeanjan thoughts?

i have been trying to compile the test code but i keep getting an error message "undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) " I'm using xcode to compile the code .

Thanks to @itzmeanjan contributions, we're now supporting more targets, which is very exciting. This also adds some complexity (maintenance, testing, ...), so I'm wondering at which point we should start using a "real library" for getting cycle count.

There's https://cpucycles.cr.yp.to/ which looks like good piece of work; however, I'm not sold on the idea of requiring installation of this library prior to using dudect. It would be great to have dudect standalone. Maybe we can take some ideas from there though.

Opening this issue for discussion. I'd say it's a low-priority issue to work on right now.

would be helpful to print before erroring out, see https://github.com/oreparaz/dudect/pull/36/files#r1470396407

Few days ago I have published a paper about the Marvin Attack in which I've used timing information to detect secret data leakage in OpenSSL, NSS, GnuTLS, and other libraries.

One of the core contributions of the paper is that timing data is not independent, and thus using tests like the Welch t-test or Kolmogorov-Smirnov test to compare them is not correct (more details are in the Out of the Box Testing paper).

The correct approach is to randomise the order in which the inputs are executed, and then use one of the paired difference tests (sign test, Wilcoxon signed-rank test, bootstrapping of median of differences, etc.) or repeated measurement tests (Friedman test, Durbin test, etc.).

Use of the correct tests also shouldn't require reporting of the raw |t| statistic, but rather could be converted to the standard, and inherently much more easy to interpret, p-value. Bootstrapping of the differences provides the information about the practical precision of the collected data, and thus can be used to say when the data set is big enough to exclude possibility of a side channel (as if it reports precision of below a single clock cycle, a leak is theoretically not possible).

Hope this will help make dudect much more robust and thus useful tool.

Hi,

I defined the DUDECT_TRACE switch and got the dudect.h:392:3: error: call to undeclared function 'wrap_report'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] error.
The fonction is not defined in dudect.h

ctx->ticks is allocated to contain ctx->config->number_measurements elements:
ctx->ticks = calloc(ctx->config->number_measurements, sizeof(int64_t));
but then it is accessed at one-beyond-the-limit position:
ctx->ticks[ctx->config->number_measurements] = cpucycles();

The link in readme, http://fdupress.net/publications.html#ct-verif seems dead. Suggestion to update it,

i have been trying to access the measurement so i can plot a cdf graph could you guide me please i really appreciate your work.

We could make dudect more portable and support other architectures, like ARM. @dfaranha wrote a port to ARM here https://github.com/dfaranha/dudect-arm that we could integrate. I think ARM would be the first target.

Right now we don't have .clang-format file for dudect, so source formatting is not consistent across IDEs. I propose we adopt "Mozilla" code style template from ClangFormat. See https://clang.llvm.org/docs/ClangFormatStyleOptions.html.

Generate .clang-format config file

clang-format --style=Mozilla --dump-config > .clang-format

And update Makefile (add new Make recipe) so that all source code living inside the repository is consistently formatted.

As in the following image, I experience a strange behavior with the print of the variable number_traces_max_t:

is it normal that it sometimes decreases?

Consider adding a new function (to be developed by the dudect user), similar to the do_one_computation() but to be executed before it and not to be included in the measurement.
I think I'll implement it.
If you want, I could share it.

We've been a bit lazy on how we're using RDTSC. The original piece of code (probably about 10 years ago) had this comment:

Intel actually recommends calling CPUID to serialize the execution flow
 and reduce variance in measurement due to out-of-order execution.
 We don't do that here yet.
 see §3.2.1 http://www.intel.com/content/www/us/en/embedded/training/ia-32-ia-64-benchmark-code-execution-paper.html

That link is gone, but the paper can be found in mirrors. It's a good resource and has the following advice. We should probably just follow it:

Resources:

• #30
• This is how @dgruss does it: https://github.com/IAIK/cache_template_attacks/blob/main/cacheutils.h#L24-L31

uint64_t rdtsc() {
  uint64_t a, d;
  asm volatile ("mfence");
  asm volatile ("rdtsc" : "=a" (a), "=d" (d));
  a = (d<<32) | a;
  asm volatile ("mfence");
  return a;
}

• This is how libcpucycles does it: https://cpucycles.cr.yp.to/libcpucycles-20230115/cpucycles/amd64-tscasm.c.html

long long ticks(void)
{
  unsigned long long result;
  asm volatile(".byte 15;.byte 49;shlq $32,%%rdx;orq %%rdx,%%rax"
    : "=a"(result) :: "%rdx");
  return result;
}

• And the motivated reader can go thru Agner Fog's tools and see: https://www.agner.org/optimize/

The test programs use the serializing instruction CPUID before and after reading the time stamp counter in order to prevent out-of-order execution to interfere with the measurements.