1741849 - Add constant-time verification through valgrind

Status: RESOLVED DUPLICATE of bug 1872936

(NSS :: Test, task, P3)

Comment 1

[Ján Jančár]

The mpi_unittest.c of the gtest-based tests has some support for verification of constant-timeness via the Valgrind technique (also described here). The build.sh file also supports the --ct-verif switch which enables the define which enables the Valgrind instrumentation necessary. The switch is somewhat badly named as there is actually a tool called ct-verif for formal verification of constant-timeness but I digress.

This issue suggests extending the approach used in that single testcase to cover more cryptographic primitives and also to actually execute the tests under Valgrind in CI (which is not done currently) and report their results.

I have a patch ready that adds the Valgrind instrumentation to bltest and fbectest and enables the --ct-verif switch to switch it on for the additional files. This allows the constant-timeness verification of primitives tested by those tests. However, what I do not have is added this testing into the CI as I do not understand the use of taskcluster/treeherder/etc. Any help in this regard would be highly appreciated.

Comment 2

[Ján Jančár]

Attachment: Bug 1741849 - Add constant-time checks to bltest and fbectest r=#nss-reviewers

Enable the --ct-verif switch to toggle the CT_VERIF define in
bltest and fbectest. Add Valgrind instrumentation for
constant-timeness checks to bltest and fbectest.

Comment 3

[Ján Jančár]

Attachment: Bug 1741849 - Add constant-time test suite r=#nss-reviewers

Adds the ct test-suite which uses Valgrind to
test the constant-timeness of crypto primitives
in NSS.

Depends on D131490

Comment 4

[Ján Jančár]

I have written a blog post about using the above two patches to analyse constant-timeness, it also has an analysis of the results. TL;DR; I think there are some leaks that deserve attention.

Comment 5

[John Schanck [:jschanck]]

Thanks for your work on this, Ján, but we're going to take a different approach. We've found that it is easier to limit the number of false positives by adding annotations within lib/freebl. Another benefit of that strategy is that lets test constant time execution of KATs, wycheproof test vectors, fuzzer-produced inputs, etc.