Add more value barriers to avoid compiler induced side channels

[randombit]

The paper https://arxiv.org/pdf/2410.13489 claims that on specific architectures Clang and GCC may introduce jumps here. The donna128 issues only affect 32-bit processors, which explains why we would not see it in the x86-64 valgrind runs.

The GHASH leak would seem to be generic but the authors only observed it on RISC-V.

[randombit]

Despite the claims in the paper, the authors never contacted me about this :disappointed: I guess we're lucky I happened to see it on a Saturday morning just before the release.

[reneme]

I wonder if it is possible to come up with (say) a custom clang-tidy rule that flags such locations for potential range analysis optimizations or the like.

[randombit]

Something that flags the obvious cases would be nice to have.

One search, that would have caught the ghash issue already, is x & 1 where x is secret, is almost certainly in need of using CT::Mask or CT::Choice, or at the very least a value barrier.

[randombit]

@atreiber94 @reneme Possible issue here https://github.com/randombit/botan/blob/master/src/lib/pubkey/frodokem/frodokem_common/frodo_matrix.cpp#L84

[coveralls]

coverage: 91.135% (+0.001%) from 91.134% when pulling 8771ae033737724afc5c9d7702ff925e62e18e0f on jack/more-value-barrier into 6babd8226963dad7b25c4ae82c4f785162727d05 on master.

[reneme]

I feel we should build a nightly test matrix that runs the valgrind suite on a wider spectrum of compilers, targets and optimization levels, in the hope that this increases the signal of such vulnerabilities. Or at least see if we can build regression tests based on our existing tools.

[randombit]

We're practically limited by what architectures are natively supported; running our tests inside qemu inside valgrind would be ... something. But adding even just x86-32 and aarch64 to the valgrind runs would improve coverage quite a bit.