Analyze Code for Timing-Based Security Vulnerabilities

This skill analyzes cryptographic code to detect operations that leak secret data through execution-timing variations - divisions and modulo on secret-derived values, branches on secrets, early-exit comparisons, weak RNG, and table lookups indexed by secret data. It ships a static analyzer (ct_analyzer/analyzer.py) that inspects assembly or bytecode across thirteen languages (C, C++, Go, Rust, Swift, Java, Kotlin, C#, PHP, JavaScript, TypeScript, Python, Ruby) and reports PASSED or FAILED with the specific dangerous instruction and function found.

Use it when a user is writing crypto code, asking about timing attacks, or when code handles secret keys/tokens - concrete triggers include implementing signature/encryption/key-derivation, code using / or % on secret-derived values, mentions of "constant-time", "timing attack", "side-channel", "KyberSlash", or functions named sign, verify, encrypt, decrypt, derive_key. Skip it for non-cryptographic code (business logic, UI), public-data processing where timing doesn't matter, code that doesn't touch secrets/keys/tokens, or high-level API usage where timing is already handled by the library.

Basic usage:

uv run {baseDir}/ct_analyzer/analyzer.py <source_file>

with --warnings for conditional-branch warnings, --func 'sign|verify' to filter functions, and --json for CI output. Native compiled languages (C, C++, Go, Rust) additionally support --arch x86_64/--arch arm64 cross-architecture testing and --opt-level O0/O3 optimization-level testing; Swift also supports both flags since it compiles to native code. Java, Kotlin, and C# analyze JVM/CIL bytecode directly (the JIT-compiled native code isn't examined), so --arch/--opt-level don't apply there. A quick-reference table maps five problems to detection signatures and fixes: division on secrets (DIV/IDIV/SDIV/UDIV, fixed via Barrett reduction or multiply-by-inverse), branch on secrets (JE/JNE/BEQ/BNE, fixed via cmov/bit masking), secret comparison (early-exit memcmp, fixed via crypto/subtle or constant-time compare), weak RNG (rand()/mt_rand/Math.random, fixed with a crypto-secure RNG), and table lookup by secret (array subscript on secret index, fixed with bit-sliced lookups).

Prerequisites per language: a compiler in PATH for C/C++/Go/Rust, Xcode/swiftc for Swift, JDK with javac/javap for Java, kotlinc plus JDK for Kotlin, .NET SDK plus ilspycmd for C#, PHP with VLD or OPcache, Node.js for JS/TS, Python 3.x, and Ruby with --dump=insns support. Because the tool has no data-flow analysis, every flagged operation must be manually verified by tracing whether its operand actually depends on secret data (a compile-time constant or public parameter like a length is a likely false positive; a value derived from a key, plaintext, or secret, or one an attacker can influence, is a true positive). Cited real-world impact: KyberSlash (2023, division timing in post-quantum ML-KEM allowed key recovery), Lucky Thirteen (2013, CBC padding-validation timing enabled plaintext recovery), and early RSA implementations leaking private-key bits through division timing.

Developers and security reviewers writing or auditing cryptographic code who need to catch timing side-channels (divisions, branches, comparisons, or lookups keyed on secret data) before they ship, verifying each flagged finding manually rather than trusting the static analyzer's output as-is.