New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check for more kinds of timing correlation in (EC)DSA #36
Comments
Sorry for not answering earlier. The test is not looking a samples with large timings since large timings are often because I'll the code so that it checks for inverse correlations between timing and the size of k. In any case, I don't see a good way to check for smaller timing differences with the given |
Thanks for the response. These are only suggestions based on my analysis of CVE-2016-5548. Feel free to resolve/close this issue at any time. I see your point about the large timings, and I agree that this is complicated by the noise that comes from warmup/JIT/GC/etc. I found a test that looks at large timings useful, but I wasn't running it in a regression test environment, and I could give the test a lot more time in order to get useful results. Still, it may be worthwhile to investigate how to do this (if you have some spare time to do so). I worry that implementers will include countermeasures that get this test to pass, but the countermeasures introduce different timing issues that are not considered by the test. |
Yup. Unfortunately, there is a chance that an implementer adds countermeasures that will not be detected by this test. The timing differences that are necessary for failing the tests are in the order of 10'000 ns, which is also about what one gets if modular exponentiation or point multiplication is used without any countermeasures. Hence the test is quite weak. But increasing the test time (which can be done by changing the constant samples in testTiming) likely has the result that the test itself is disabled in continuous tests. Since detecting timing differences that are n times smaller requires about n^2 times more samples, it seems hopeless to me to get good results with the current test. However, the tests don't have to simulate an actual attack, they just have to detect weak implementations. This may allow to use information that are typically not available to an attacker. E.g. one option to consider is to profile signature generation and check if k correlates with the number of internal function calls. |
The DSA timing test in DsaTest.testTiming() (and the equivalent ECDSA test) currently looks for small k values that are correlated with short timings. I would like to suggest the following enhancements:
The text was updated successfully, but these errors were encountered: