Description
In my most superficial of reviews, constant-time comparison appears to not be globally implemented (at a glance, only implemented within the ref10 implementation).
With that said, the following areas either appear to be vulnerable, or are potentially vulnerable, to key-timing attacks:
Containers used for RingCT (in particular, the key struct) as deployed throughout RingCT
The definition and implementations of CRYPTOMAKECOMPARABLE
equalKeys in rctOps.cpp, whose comparison speed appears to be relative to its available hardware
For points 1 and 2, as a steadfast rule; do NOT use memcmp when comparing cryptographic secrets (or any cryptographic material for that matter). For point 3, be careful with conditional branches which can be optimized or subject to speculative execution. One possible fix for point 3 is to perform an XOR of all the bytes in both buffers, and then compare the result (see kovri below).
As the literature states, key timing vulnerabilities can range from somewhat-trivial to extremely-difficult to exploit. For this report, I cannot assess a difficulty. For an active attack, monero has a very simple yet friendly network layer which I imagine could make remote execution somewhat easier (depending on the context and application) but, I don't have PoC. Now, at the local level for, let's say, a malicious node that wants to forge X before sending to the next peer, the results could be easier to attain (again, no PoC).
This was only the most superficial of reviews - so please forgive any assumptions or inaccuracies on my part. If I had more time with this issue, I would love to look deeper in order to provide a more details and to assert a monero PoC. Unfortunately, I am too busy with kovri - but I hope that this report will at least raises awareness.
Vector: BVSS:1.1/B:N/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H/CI:N/II:H/AI:N