Implement value barrier and apply to FrodoKEM

[xuganyu96]

Summary

This pull request implements a OQS_MEM_BLACK_BOX macro, which serves as a frontend to a variety of implementations of value barriers:

• Use inline assembly __asm__ volatile("" : "+r"(v) :) where available
• Use a volatile round-trip that reads and writes every byte in the input buffer as a fallback

The black box is then applied to FrodoKEM's ct_select to prevent compiler from reasoning about selector when inlining ct_select.

Code change

value barrier implementation and application

• src/common/common.h
• src/kem/frodokem/external/util.c

Test harness for detecting cache timing side channel in FO-transformed KEM

• tests/CMakeLists.txt
• tests/kem_fo_cache_oracle.c
• tests/kem_fo_cache_oracle.py

Thanks to @kaminuma for providing the initial PoC.

kem_fo_cache_oracle.c is a command-line program that measures the time it takes to read from a user-specified location of the KEM secret key after decapsulating some valid and/or invalid ciphertexts.
kem_fo_cache_oracle.py is a Python script that performs statistical analysis of the raw timing measurements from kem_fo_cache_oracle.c program.
Commands for using these two programs were documented in CONFIGURE.md.

Validation

Manually verify the absence of conditional memory reads from the compiled assembly with the following build commands:

# Apple Silicon, Homebrew Clang 18, MacOS 26.4
cmake -GNinja \
    -DCMAKE_C_FLAGS="-DOQS_DISABLE_MEM_BLACK_BOX" \
    -DCMAKE_C_COMPILER="/opt/homebrew/bin/clang-18" \
    -DCMAKE_BUILD_TYPE="MinSizeRel" \
    -DCMAKE_OSX_DEPLOYMENT_TARGET="26.0" \
    -DOQS_MINIMAL_BUILD="KEM_frodokem_640_aes" \
    .. 
    && ninja \
    && objdump -d lib/liboqs.a > liboqs.a.S

• With -DOQS_DISABLE_MEM_BLACK_BOX, <OQS_KEM_frodokem_640_aes_decaps> contains a csel instruction.
• Without -DOQS_DISABLE_MEM_BLACK_BOX, <OQS_KEM_frodokem_640_aes_decaps> does not contain csel instruction. This is true for all FrodoKEM parameters (with the OQS_MINIMAL_BUILD options removed).
• Without -DOQS_DISABLE_MEM_BLACK_BOX, but modifying source code to force fallback, <OQS_KEM_frodokem_640_aes_decaps> does not contain csel either.

LLM disclosure

kem_fo_cache_oracle.py is generated with help from Claude.

• [NO] Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• [NO] Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged. Also, make sure to update the list of algorithms in the continuous benchmarking files: .github/workflows/kem-bench.yml and sig-bench.yml)

[coveralls]

coverage: 82.263% (-0.004%) from 82.267% — GHSA-5c97-hp95-vg56 into main

[bhess]

Thanks @xuganyu96 for adding this very useful feature.

I haven’t reviewed the FO cache oracle test in detail, but will this be run in CI? If not, is there a plan to run it regularly?

Regarding the countermeasures:

Use inline assembly __asm__ volatile("" : "+r"(v) :) where available
Use a volatile round-trip that reads and writes every byte in the input buffer as a fallback

I have two comments/questions:

1. It might be good to document with a rationale or related work why they are effective.
2. The fallback option (reading and writing every byte) seems potentially expensive if it is used with larger data structures than with the selector byte. Were there more efficient alternatives considered?

See also the comments inline.

[xuganyu96]

@bhess

will this be run in CI? If not, is there a plan to run it regularly?

I don't plan to run this on GitHub Actions because the cache timing test must run on bare metal for cache eviction to be meaningful and for timing measurements to be accurate. I've added a line to CONFIGURE.md explaining this.

It might be good to document with a rationale or related work why they are
effective.

I borrowed the inline ASM optimization barrier from mlkem-native. Here is one example. I am not sure if there is any official documents recommending this pattern, but it does seem to be the gold standard across many prominent projects.

The fallback option (reading and writing every byte) seems potentially
expensive if it is used with larger data structures than with the selector
byte. Were there more efficient alternatives considered?

The fallback option is meant to cover for Windows builds, since MSVC does not support inline assembly in the same way GNU/LLVM does. I plan to follow up in a subsequent patch to add an appropriate MSVC backend for optimization barrier. This round trip is just an unfortunate temporary band-aid.

[bhess]

Thanks @xuganyu96 for the update.

I borrowed the inline ASM optimization barrier from mlkem-native. Here is one example. I am not sure if there is any official documents recommending this pattern, but it does seem to be the gold standard across many prominent projects.

Can we document this somewhere (e.g., as code comment, reference to mlkem-native). Might be helpful to keep the reference.

[baentsch]

Why just FrodoKEM-640-AES? Worthwhile listing all algs this could be applied to (be arguments)?

[baentsch]

This Usage sample seems to disagree with the script's name. Intentional?