[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DSNN7RT0T8PAPSC04B2HB5":3,"skill-same:01M6DSNN7RT0T8PAPSC04B2HB5":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":42,"install":43,"resources":56},"01M6DSNN7RT0T8PAPSC04B2HB5","constant-time-testing",null,"Constant-time testing detects timing side channels in cryptographic code. Use when auditing crypto implementations for timing vulnerabilities.","AntifragileTech\u002Fantifragile-claude-code","AntifragileTech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F174357194?v=4","01M6DQCYMK4CDSQQAN0ZC72NTV","01M6DQCYS9YPW1WKMQ5TJMPQ43",9,"MIT","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fsecurity\u002Fconstant-time-testing\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30],"testing","time","constant time testing","vulnerabilities","code","use","crypto","domain","2026-11-10 10:12:30",false,"---\nname: constant-time-testing\ntype: domain\ndescription: >\n  Constant-time testing detects timing side channels in cryptographic code.\n  Use when auditing crypto implementations for timing vulnerabilities.\n---\n\n# Constant-Time Testing\n\nTiming attacks exploit variations in execution time to extract secret information from cryptographic implementations. Unlike cryptanalysis that targets theoretical weaknesses, timing attacks leverage implementation flaws - and they can affect any cryptographic code.\n\n## Background\n\nTiming attacks were introduced by [Kocher](https:\u002F\u002Fpaulkocher.com\u002Fdoc\u002FTimingAttacks.pdf) in 1996. Since then, researchers have demonstrated practical attacks on RSA ([Schindler](https:\u002F\u002Flink.springer.com\u002Fcontent\u002Fpdf\u002F10.1007\u002F3-540-44499-8_8.pdf)), OpenSSL ([Brumley and Boneh](https:\u002F\u002Fcrypto.stanford.edu\u002F~dabo\u002Fpapers\u002Fssl-timing.pdf)), AES implementations, and even post-quantum algorithms like [Kyber](https:\u002F\u002Feprint.iacr.org\u002F2024\u002F1049.pdf).\n\n### Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| Constant-time | Code path and memory accesses independent of secret data |\n| Timing leakage | Observable execution time differences correlated with secrets |\n| Side channel | Information extracted from implementation rather than algorithm |\n| Microarchitecture | CPU-level timing differences (cache, division, shifts) |\n\n### Why This Matters\n\nTiming vulnerabilities can:\n- **Expose private keys** - Extract secret exponents in RSA\u002FECDH\n- **Enable remote attacks** - Network-observable timing differences\n- **Bypass cryptographic security** - Undermine theoretical guarantees\n- **Persist silently** - Often undetected without specialized analysis\n\nTwo prerequisites enable exploitation:\n1. **Access to oracle** - Sufficient queries to the vulnerable implementation\n2. **Timing dependency** - Correlation between execution time and secret data\n\n### Common Constant-Time Violation Patterns\n\nFour patterns account for most timing vulnerabilities:\n\n```c\n\u002F\u002F 1. Conditional jumps - most severe timing differences\nif(secret == 1) { ... }\nwhile(secret > 0) { ... }\n\n\u002F\u002F 2. Array access - cache-timing attacks\nlookup_table[secret];\n\n\u002F\u002F 3. Integer division (processor dependent)\ndata = secret \u002F m;\n\n\u002F\u002F 4. Shift operation (processor dependent)\ndata = a \u003C\u003C secret;\n```\n\n**Conditional jumps** cause different code paths, leading to vast timing differences.\n\n**Array access** dependent on secrets enables cache-timing attacks, as shown in [AES cache-timing research](https:\u002F\u002Fcr.yp.to\u002Fantiforgery\u002Fcachetiming-20050414.pdf).\n\n**Integer division and shift operations** leak secrets on certain CPU architectures and compiler configurations.\n\nWhen patterns cannot be avoided, employ [masking techniques](https:\u002F\u002Flink.springer.com\u002Fchapter\u002F10.1007\u002F978-3-642-38348-9_9) to remove correlation between timing and secrets.\n\n### Example: Modular Exponentiation Timing Attacks\n\nModular exponentiation (used in RSA and Diffie-Hellman) is susceptible to timing attacks. RSA decryption computes:\n\n$$ct^{d} \\mod{N}$$\n\nwhere $d$ is the secret exponent. The *exponentiation by squaring* optimization reduces multiplications to $\\log{d}$:\n\n$$\n\\begin{align*}\n& \\textbf{Input: } \\text{base }y,\\text{exponent } d=\\{d_n,\\cdots,d_0\\}_2,\\text{modulus } N \\\\\n& r = 1 \\\\\n& \\textbf{for } i=|n| \\text{ downto } 0: \\\\\n& \\quad\\textbf{if } d_i == 1: \\\\\n& \\quad\\quad r = r * y \\mod{N} \\\\\n& \\quad y = y * y \\mod{N} \\\\\n& \\textbf{return }r\n\\end{align*}\n$$\n\nThe code branches on exponent bit $d_i$, violating constant-time principles. When $d_i = 1$, an additional multiplication occurs, increasing execution time and leaking bit information.\n\nMontgomery multiplication (commonly used for modular arithmetic) also leaks timing: when intermediate values exceed modulus $N$, an additional reduction step is required. An attacker constructs inputs $y$ and $y'$ such that:\n\n$$\n\\begin{align*}\ny^2 \u003C y^3 \u003C N \\\\\ny'^2 \u003C N \\leq y'^3\n\\end{align*}\n$$\n\nFor $y$, both multiplications take time $t_1+t_1$. For $y'$, the second multiplication requires reduction, taking time $t_1+t_2$. This timing difference reveals whether $d_i$ is 0 or 1.\n\n## When to Use\n\n**Apply constant-time analysis when:**\n- Auditing cryptographic implementations (primitives, protocols)\n- Code handles secret keys, passwords, or sensitive cryptographic material\n- Implementing crypto algorithms from scratch\n- Reviewing PRs that touch crypto code\n- Investigating potential timing vulnerabilities\n\n**Consider alternatives when:**\n- Code does not process secret data\n- Public algorithms with no secret inputs\n- Non-cryptographic timing requirements (performance optimization)\n\n## Quick Reference\n\n| Scenario | Recommended Approach | Skill |\n|----------|---------------------|-------|\n| Prove absence of leaks | Formal verification | SideTrail, ct-verif, FaCT |\n| Detect statistical timing differences | Statistical testing | **dudect** |\n| Track secret data flow at runtime | Dynamic analysis | **timecop** |\n| Find cache-timing vulnerabilities | Symbolic execution | Binsec, pitchfork |\n\n## Constant-Time Tooling Categories\n\nThe cryptographic community has developed four categories of timing analysis tools:\n\n| Category | Approach | Pros | Cons |\n|----------|----------|------|------|\n| **Formal** | Mathematical proof on model | Guarantees absence of leaks | Complexity, modeling assumptions |\n| **Symbolic** | Symbolic execution paths | Concrete counterexamples | Time-intensive path exploration |\n| **Dynamic** | Runtime tracing with marked secrets | Granular, flexible | Limited coverage to executed paths |\n| **Statistical** | Measure real execution timing | Practical, simple setup | No root cause, noise sensitivity |\n\n### 1. Formal Tools\n\nFormal verification mathematically proves timing properties on an abstraction (model) of code. Tools create a model from source\u002Fbinary and verify it satisfies specified properties (e.g., variables annotated as secret).\n\n**Popular tools:**\n- [SideTrail](https:\u002F\u002Fgithub.com\u002Faws\u002Fs2n-tls\u002Ftree\u002Fmain\u002Ftests\u002Fsidetrail)\n- [ct-verif](https:\u002F\u002Fgithub.com\u002Fimdea-software\u002Fverifying-constant-time)\n- [FaCT](https:\u002F\u002Fgithub.com\u002Fplsyssec\u002Ffact)\n\n**Strengths:** Proof of absence, language-agnostic (LLVM bytecode)\n**Weaknesses:** Requires expertise, modeling assumptions may miss real-world issues\n\n### 2. Symbolic Tools\n\nSymbolic execution analyzes how paths and memory accesses depend on symbolic variables (secrets). Provides concrete counterexamples. Focus on cache-timing attacks.\n\n**Popular tools:**\n- [Binsec](https:\u002F\u002Fgithub.com\u002Fbinsec\u002Fbinsec)\n- [pitchfork](https:\u002F\u002Fgithub.com\u002FPLSysSec\u002Fhaybale-pitchfork)\n\n**Strengths:** Concrete counterexamples aid debugging\n**Weaknesses:** Path explosion leads to long execution times\n\n### 3. Dynamic Tools\n\nDynamic analysis marks sensitive memory regions and traces execution to detect timing-dependent operations.\n\n**Popular tools:**\n- [Memsan](https:\u002F\u002Fclang.llvm.org\u002Fdocs\u002FMemorySanitizer.html): [Tutorial](https:\u002F\u002Fcrocs-muni.github.io\u002Fct-tools\u002Ftutorials\u002Fmemsan)\n- **Timecop** (see below)\n\n**Strengths:** Granular control, targeted analysis\n**Weaknesses:** Coverage limited to executed paths\n\n> **Detailed Guidance:** See the **timecop** skill for setup and usage.\n\n### 4. Statistical Tools\n\nExecute code with various inputs, measure elapsed time, and detect inconsistencies. Tests actual implementation including compiler optimizations and architecture.\n\n**Popular tools:**\n- **dudect** (see below)\n- [tlsfuzzer](https:\u002F\u002Fgithub.com\u002Ftlsfuzzer\u002Ftlsfuzzer)\n\n**Strengths:** Simple setup, practical real-world results\n**Weaknesses:** No root cause info, noise obscures weak signals\n\n> **Detailed Guidance:** See the **dudect** skill for setup and usage.\n\n## Testing Workflow\n\n```\nPhase 1: Static Analysis        Phase 2: Statistical Testing\n┌─────────────────┐            ┌─────────────────┐\n│ Identify secret │      →     │ Detect timing   │\n│ data flow       │            │ differences     │\n│ Tool: ct-verif  │            │ Tool: dudect    │\n└─────────────────┘            └─────────────────┘\n         ↓                              ↓\nPhase 4: Root Cause             Phase 3: Dynamic Tracing\n┌─────────────────┐            ┌─────────────────┐\n│ Pinpoint leak   │      ←     │ Track secret    │\n│ location        │            │ propagation     │\n│ Tool: Timecop   │            │ Tool: Timecop   │\n└─────────────────┘            └─────────────────┘\n```\n\n**Recommended approach:**\n1. **Start with dudect** - Quick statistical check for timing differences\n2. **If leaks found** - Use Timecop to pinpoint root cause\n3. **For high-assurance** - Apply formal verification (ct-verif, SideTrail)\n4. **Continuous monitoring** - Integrate dudect into CI pipeline\n\n## Tools and Approaches\n\n### Dudect - Statistical Analysis\n\n[Dudect](https:\u002F\u002Fgithub.com\u002Foreparaz\u002Fdudect\u002F) measures execution time for two input classes (fixed vs random) and uses Welch's t-test to detect statistically significant differences.\n\n> **Detailed Guidance:** See the **dudect** skill for complete setup, usage patterns, and CI integration.\n\n#### Quick Start for Constant-Time Analysis\n\n```c\n#define DUDECT_IMPLEMENTATION\n#include \"dudect.h\"\n\nuint8_t do_one_computation(uint8_t *data) {\n    \u002F\u002F Code to measure goes here\n}\n\nvoid prepare_inputs(dudect_config_t *c, uint8_t *input_data, uint8_t *classes) {\n    for (size_t i = 0; i \u003C c->number_measurements; i++) {\n        classes[i] = randombit();\n        uint8_t *input = input_data + (size_t)i * c->chunk_size;\n        if (classes[i] == 0) {\n            \u002F\u002F Fixed input class\n        } else {\n            \u002F\u002F Random input class\n        }\n    }\n}\n```\n\n**Key advantages:**\n- Simple C header-only integration\n- Statistical rigor via Welch's t-test\n- Works with compiled binaries (real-world conditions)\n\n**Key limitations:**\n- No root cause information when leak detected\n- Sensitive to measurement noise\n- Cannot guarantee absence of leaks (statistical confidence only)\n\n### Timecop - Dynamic Tracing\n\n[Timecop](https:\u002F\u002Fpost-apocalyptic-crypto.org\u002Ftimecop\u002F) wraps Valgrind to detect runtime operations dependent on secret memory regions.\n\n> **Detailed Guidance:** See the **timecop** skill for installation, examples, and debugging.\n\n#### Quick Start for Constant-Time Analysis\n\n```c\n#include \"valgrind\u002Fmemcheck.h\"\n\n#define poison(addr, len) VALGRIND_MAKE_MEM_UNDEFINED(addr, len)\n#define unpoison(addr, len) VALGRIND_MAKE_MEM_DEFINED(addr, len)\n\nint main() {\n    unsigned long long secret_key = 0x12345678;\n\n    \u002F\u002F Mark secret as poisoned\n    poison(&secret_key, sizeof(secret_key));\n\n    \u002F\u002F Any branching or memory access dependent on secret_key\n    \u002F\u002F will be reported by Valgrind\n    crypto_operation(secret_key);\n\n    unpoison(&secret_key, sizeof(secret_key));\n}\n```\n\nRun with Valgrind:\n```bash\nvalgrind --leak-check=full --track-origins=yes .\u002Fbinary\n```\n\n**Key advantages:**\n- Pinpoints exact line of timing leak\n- No code instrumentation required\n- Tracks secret propagation through execution\n\n**Key limitations:**\n- Cannot detect microarchitecture timing differences\n- Coverage limited to executed paths\n- Performance overhead (runs on synthetic CPU)\n\n## Implementation Guide\n\n### Phase 1: Initial Assessment\n\n**Identify cryptographic code handling secrets:**\n- Private keys, exponents, nonces\n- Password hashes, authentication tokens\n- Encryption\u002Fdecryption operations\n\n**Quick statistical check:**\n1. Write dudect harness for the crypto function\n2. Run for 5-10 minutes with `timeout 600 .\u002Fct_test`\n3. Monitor t-value: high absolute values indicate leakage\n\n**Tools:** dudect\n**Expected time:** 1-2 hours (harness writing + initial run)\n\n### Phase 2: Detailed Analysis\n\nIf dudect detects leakage:\n\n**Root cause investigation:**\n1. Mark secret variables with Timecop `poison()`\n2. Run under Valgrind to identify exact line\n3. Review the four common violation patterns\n4. Check assembly output for conditional branches\n\n**Tools:** Timecop, compiler output (`objdump -d`)\n\n### Phase 3: Remediation\n\n**Fix the timing leak:**\n- Replace conditional branches with constant-time selection (bitwise operations)\n- Use constant-time comparison functions\n- Replace array lookups with constant-time alternatives or masking\n- Verify compiler doesn't optimize away constant-time code\n\n**Re-verify:**\n1. Run dudect again for extended period (30+ minutes)\n2. Test across different compilers and optimization levels\n3. Test on different CPU architectures\n\n### Phase 4: Continuous Monitoring\n\n**Integrate into CI:**\n- Add dudect tests to test suite\n- Run for fixed duration (5-10 minutes in CI)\n- Fail build if leakage detected\n\nSee the **dudect** skill for CI integration examples.\n\n## Common Vulnerabilities\n\n| Vulnerability | Description | Detection | Severity |\n|---------------|-------------|-----------|----------|\n| Secret-dependent branch | `if (secret_bit) { ... }` | dudect, Timecop | CRITICAL |\n| Secret-dependent array access | `table[secret_index]` | Timecop, Binsec | HIGH |\n| Variable-time division | `result = x \u002F secret` | Timecop | MEDIUM |\n| Variable-time shift | `result = x \u003C\u003C secret` | Timecop | MEDIUM |\n| Montgomery reduction leak | Extra reduction when intermediate > N | dudect | HIGH |\n\n### Secret-Dependent Branch: Deep Dive\n\n**The vulnerability:**\nExecution time differs based on whether branch is taken. Common in optimized modular exponentiation (square-and-multiply).\n\n**How to detect with dudect:**\n```c\nuint8_t do_one_computation(uint8_t *data) {\n    uint64_t base = ((uint64_t*)data)[0];\n    uint64_t exponent = ((uint64_t*)data)[1]; \u002F\u002F Secret!\n    return mod_exp(base, exponent, MODULUS);\n}\n\nvoid prepare_inputs(dudect_config_t *c, uint8_t *input_data, uint8_t *classes) {\n    for (size_t i = 0; i \u003C c->number_measurements; i++) {\n        classes[i] = randombit();\n        uint64_t *input = (uint64_t*)(input_data + i * c->chunk_size);\n        input[0] = rand(); \u002F\u002F Random base\n        input[1] = (classes[i] == 0) ? FIXED_EXPONENT : rand(); \u002F\u002F Fixed vs random\n    }\n}\n```\n\n**How to detect with Timecop:**\n```c\npoison(&exponent, sizeof(exponent));\nresult = mod_exp(base, exponent, modulus);\nunpoison(&exponent, sizeof(exponent));\n```\n\nValgrind will report:\n```\nConditional jump or move depends on uninitialised value(s)\n  at 0x40115D: mod_exp (example.c:14)\n```\n\n**Related skill:** **dudect**, **timecop**\n\n## Case Studies\n\n### Case Study: OpenSSL RSA Timing Attack\n\nBrumley and Boneh (2005) extracted RSA private keys from OpenSSL over a network. The vulnerability exploited Montgomery multiplication's variable-time reduction step.\n\n**Attack vector:** Timing differences in modular exponentiation\n**Detection approach:** Statistical analysis (precursor to dudect)\n**Impact:** Remote key extraction\n\n**Tools used:** Custom timing measurement\n**Techniques applied:** Statistical analysis, chosen-ciphertext queries\n\n### Case Study: KyberSlash\n\nPost-quantum algorithm Kyber's reference implementation contained timing vulnerabilities in polynomial operations. Division operations leaked secret coefficients.\n\n**Attack vector:** Secret-dependent division timing\n**Detection approach:** Dynamic analysis and statistical testing\n**Impact:** Secret key recovery in post-quantum cryptography\n\n**Tools used:** Timing measurement tools\n**Techniques applied:** Differential timing analysis\n\n## Advanced Usage\n\n### Tips and Tricks\n\n| Tip | Why It Helps |\n|-----|--------------|\n| Pin dudect to isolated CPU core (`taskset -c 2`) | Reduces OS noise, improves signal detection |\n| Test multiple compilers (gcc, clang, MSVC) | Optimizations may introduce or remove leaks |\n| Run dudect for extended periods (hours) | Increases statistical confidence |\n| Minimize non-crypto code in harness | Reduces noise that masks weak signals |\n| Check assembly output (`objdump -d`) | Verify compiler didn't introduce branches |\n| Use `-O3 -march=native` in testing | Matches production optimization levels |\n\n### Common Mistakes\n\n| Mistake | Why It's Wrong | Correct Approach |\n|---------|----------------|------------------|\n| Only testing one input distribution | May miss leaks visible with other patterns | Test fixed-vs-random, fixed-vs-fixed-different, etc. |\n| Short dudect runs (\u003C 1 minute) | Insufficient measurements for weak signals | Run 5-10+ minutes, longer for high assurance |\n| Ignoring compiler optimization levels | `-O0` may hide leaks present in `-O3` | Test at production optimization level |\n| Not testing on target architecture | x86 vs ARM have different timing characteristics | Test on deployment platform |\n| Marking too much as secret in Timecop | False positives, unclear results | Mark only true secrets (keys, not public data) |\n\n## Related Skills\n\n### Tool Skills\n\n| Skill | Primary Use in Constant-Time Analysis |\n|-------|---------------------------------------|\n| **dudect** | Statistical detection of timing differences via Welch's t-test |\n| **timecop** | Dynamic tracing to pinpoint exact location of timing leaks |\n\n### Technique Skills\n\n| Skill | When to Apply |\n|-------|---------------|\n| **coverage-analysis** | Ensure test inputs exercise all code paths in crypto function |\n| **ci-integration** | Automate constant-time testing in continuous integration pipeline |\n\n### Related Domain Skills\n\n| Skill | Relationship |\n|-------|--------------|\n| **crypto-testing** | Constant-time analysis is essential component of cryptographic testing |\n| **fuzzing** | Fuzzing crypto code may trigger timing-dependent paths |\n\n## Skill Dependency Map\n\n```\n                    ┌─────────────────────────┐\n                    │  constant-time-analysis │\n                    │     (this skill)        │\n                    └───────────┬─────────────┘\n                                │\n                ┌───────────────┴───────────────┐\n                │                               │\n                ▼                               ▼\n    ┌───────────────────┐           ┌───────────────────┐\n    │      dudect       │           │     timecop       │\n    │  (statistical)    │           │    (dynamic)      │\n    └────────┬──────────┘           └────────┬──────────┘\n             │                               │\n             └───────────────┬───────────────┘\n                             │\n                             ▼\n              ┌──────────────────────────────┐\n              │   Supporting Techniques      │\n              │ coverage, CI integration     │\n              └──────────────────────────────┘\n```\n\n## Resources\n\n### Key External Resources\n\n**[These results must be false: A usability evaluation of constant-time analysis tools](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fsec24fall-prepub-760-fourne.pdf)**\nComprehensive usability study of constant-time analysis tools. Key findings: developers struggle with false positives, need better error messages, and benefit from tool integration. Evaluates FaCT, ct-verif, dudect, and Memsan across multiple cryptographic implementations. Recommends improved tooling UX and better documentation.\n\n**[List of constant-time tools - CROCS](https:\u002F\u002Fcrocs-muni.github.io\u002Fct-tools\u002F)**\nCurated catalog of constant-time analysis tools with tutorials. Covers formal tools (ct-verif, FaCT), dynamic tools (Memsan, Timecop), symbolic tools (Binsec), and statistical tools (dudect). Includes practical tutorials for setup and usage.\n\n**[Paul Kocher: Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems](https:\u002F\u002Fpaulkocher.com\u002Fdoc\u002FTimingAttacks.pdf)**\nOriginal 1996 paper introducing timing attacks. Demonstrates attacks on modular exponentiation in RSA and Diffie-Hellman. Essential historical context for understanding timing vulnerabilities.\n\n**[Remote Timing Attacks are Practical (Brumley & Boneh)](https:\u002F\u002Fcrypto.stanford.edu\u002F~dabo\u002Fpapers\u002Fssl-timing.pdf)**\nDemonstrates practical remote timing attacks against OpenSSL. Shows network-level timing differences are sufficient to extract RSA keys. Proves timing attacks work in realistic network conditions.\n\n**[Cache-timing attacks on AES](https:\u002F\u002Fcr.yp.to\u002Fantiforgery\u002Fcachetiming-20050414.pdf)**\nShows AES implementations using lookup tables are vulnerable to cache-timing attacks. Demonstrates practical attacks extracting AES keys via cache timing side channels.\n\n**[KyberSlash: Division Timings Leak Secrets](https:\u002F\u002Feprint.iacr.org\u002F2024\u002F1049.pdf)**\nRecent discovery of timing vulnerabilities in Kyber (NIST post-quantum standard). Shows division operations leak secret coefficients. Highlights that constant-time issues persist even in modern post-quantum cryptography.\n\n### Video Resources\n\n- [Trail of Bits: Constant-Time Programming](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=vW6wqTzfz5g) - Overview of constant-time programming principles and tools\n","# Constant-Time Testing\n\nTiming attacks exploit variations in execution time to extract secret information from cryptographic implementations. Unlike cryptanalysis that targets theoretical weaknesses, timing attacks leverage implementation flaws - and they can affect any cryptographic code.\n\n## Background\n\nTiming attacks were introduced by [Kocher](https:\u002F\u002Fpaulkocher.com\u002Fdoc\u002FTimingAttacks.pdf) in 1996. Since then, researchers have demonstrated practical attacks on RSA ([Schindler](https:\u002F\u002Flink.springer.com\u002Fcontent\u002Fpdf\u002F10.1007\u002F3-540-44499-8_8.pdf)), OpenSSL ([Brumley and Boneh](https:\u002F\u002Fcrypto.stanford.edu\u002F~dabo\u002Fpapers\u002Fssl-timing.pdf)), AES implementations, and even post-quantum algorithms like [Kyber](https:\u002F\u002Feprint.iacr.org\u002F2024\u002F1049.pdf).\n\n### Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| Constant-time | Code path and memory accesses independent of secret data |\n| Timing leakage | Observable execution time differences correlated with secrets |\n| Side channel | Information extracted from implementation rather than algorithm |\n| Microarchitecture | CPU-level timing differences (cache, division, shifts) |\n\n### Why This Matters\n\nTiming vulnerabilities can:\n- **Expose private keys** - Extract secret exponents in RSA\u002FECDH\n- **Enable remote attacks** - Network-observable timing differences\n- **Bypass cryptographic security** - Undermine theoretical guarantees\n- **Persist silently** - Often undetected without specialized analysis\n\nTwo prerequisites enable exploitation:\n1. **Access to oracle** - Sufficient queries to the vulnerable implementation\n2. **Timing dependency** - Correlation between execution time and secret data\n\n### Common Constant-Time Violation Patterns\n\nFour patterns account for most timing vulnerabilities:\n\n```c\n\u002F\u002F 1. Conditional jumps - most severe timing differences\nif(secret == 1) { ... }\nwhile(secret > 0) { ... }\n\n\u002F\u002F 2. Array access - cache-timing attacks\nlookup_table[secret];\n\n\u002F\u002F 3. Integer division (processor dependent)\ndata = secret \u002F m;\n\n\u002F\u002F 4. Shift operation (processor dependent)\ndata = a \u003C\u003C secret;\n```\n\n**Conditional jumps** cause different code paths, leading to vast timing differences.\n\n**Array access** dependent on secrets enables cache-timing attacks, as shown in [AES cache-timing research](https:\u002F\u002Fcr.yp.to\u002Fantiforgery\u002Fcachetiming-20050414.pdf).\n\n**Integer division and shift operations** leak secrets on certain CPU architectures and compiler configurations.\n\nWhen patterns cannot be avoided, employ [masking techniques](https:\u002F\u002Flink.springer.com\u002Fchapter\u002F10.1007\u002F978-3-642-38348-9_9) to remove correlation between timing and secrets.\n\n### Example: Modular Exponentiation Timing Attacks\n\nModular exponentiation (used in RSA and Diffie-Hellman) is susceptible to timing attacks. RSA decryption computes:\n\n$$ct^{d} \\mod{N}$$\n\nwhere $d$ is the secret exponent. The *exponentiation by squaring* optimization reduces multiplications to $\\log{d}$:\n\n$$\n\\begin{align*}\n& \\textbf{Input: } \\text{base }y,\\text{exponent } d=\\{d_n,\\cdots,d_0\\}_2,\\text{modulus } N \\\\\n& r = 1 \\\\\n& \\textbf{for } i=|n| \\text{ downto } 0: \\\\\n& \\quad\\textbf{if } d_i == 1: \\\\\n& \\quad\\quad r = r * y \\mod{N} \\\\\n& \\quad y = y * y \\mod{N} \\\\\n& \\textbf{return }r\n\\end{align*}\n$$\n\nThe code branches on exponent bit $d_i$, violating constant-time principles. When $d_i = 1$, an additional multiplication occurs, increasing execution time and leaking bit information.\n\nMontgomery multiplication (commonly used for modular arithmetic) also leaks timing: when intermediate values exceed modulus $N$, an additional reduction step is required. An attacker constructs inputs $y$ and $y'$ such that:\n\n$$\n\\begin{align*}\ny^2 \u003C y^3 \u003C N \\\\\ny'^2 \u003C N \\leq y'^3\n\\end{align*}\n$$\n\nFor $y$, both multiplications take time $t_1+t_1$. For $y'$, the second multiplication requires reduction, taking time $t_1+t_2$. This timing difference reveals whether $d_i$ is 0 or 1.\n\n## When to Use\n\n**Apply constant-time analysis when:**\n- Auditing cryptographic implementations (primitives, protocols)\n- Code handles secret keys, passwords, or sensitive cryptographic material\n- Implementing crypto algorithms from scratch\n- Reviewing PRs that touch crypto code\n- Investigating potential timing vulnerabilities\n\n**Consider alternatives when:**\n- Code does not process secret data\n- Public algorithms with no secret inputs\n- Non-cryptographic timing requirements (performance optimization)\n\n## Quick Reference\n\n| Scenario | Recommended Approach | Skill |\n|----------|---------------------|-------|\n| Prove absence of leaks | Formal verification | SideTrail, ct-verif, FaCT |\n| Detect statistical timing differences | Statistical testing | **dudect** |\n| Track secret data flow at runtime | Dynamic analysis | **timecop** |\n| Find cache-timing vulnerabilities | Symbolic execution | Binsec, pitchfork |\n\n## Constant-Time Tooling Categories\n\nThe cryptographic community has developed four categories of timing analysis tools:\n\n| Category | Approach | Pros | Cons |\n|----------|----------|------|------|\n| **Formal** | Mathematical proof on model | Guarantees absence of leaks | Complexity, modeling assumptions |\n| **Symbolic** | Symbolic execution paths | Concrete counterexamples | Time-intensive path exploration |\n| **Dynamic** | Runtime tracing with marked secrets | Granular, flexible | Limited coverage to executed paths |\n| **Statistical** | Measure real execution timing | Practical, simple setup | No root cause, noise sensitivity |\n\n### 1. Formal Tools\n\nFormal verification mathematically proves timing properties on an abstraction (model) of code. Tools create a model from source\u002Fbinary and verify it satisfies specified properties (e.g., variables annotated as secret).\n\n**Popular tools:**\n- [SideTrail](https:\u002F\u002Fgithub.com\u002Faws\u002Fs2n-tls\u002Ftree\u002Fmain\u002Ftests\u002Fsidetrail)\n- [ct-verif](https:\u002F\u002Fgithub.com\u002Fimdea-software\u002Fverifying-constant-time)\n- [FaCT](https:\u002F\u002Fgithub.com\u002Fplsyssec\u002Ffact)\n\n**Strengths:** Proof of absence, language-agnostic (LLVM bytecode)\n**Weaknesses:** Requires expertise, modeling assumptions may miss real-world issues\n\n### 2. Symbolic Tools\n\nSymbolic execution analyzes how paths and memory accesses depend on symbolic variables (secrets). Provides concrete counterexamples. Focus on cache-timing attacks.\n\n**Popular tools:**\n- [Binsec](https:\u002F\u002Fgithub.com\u002Fbinsec\u002Fbinsec)\n- [pitchfork](https:\u002F\u002Fgithub.com\u002FPLSysSec\u002Fhaybale-pitchfork)\n\n**Strengths:** Concrete counterexamples aid debugging\n**Weaknesses:** Path explosion leads to long execution times\n\n### 3. Dynamic Tools\n\nDynamic analysis marks sensitive memory regions and traces execution to detect timing-dependent operations.\n\n**Popular tools:**\n- [Memsan](https:\u002F\u002Fclang.llvm.org\u002Fdocs\u002FMemorySanitizer.html): [Tutorial](https:\u002F\u002Fcrocs-muni.github.io\u002Fct-tools\u002Ftutorials\u002Fmemsan)\n- **Timecop** (see below)\n\n**Strengths:** Granular control, targeted analysis\n**Weaknesses:** Coverage limited to executed paths\n\n> **Detailed Guidance:** See the **timecop** skill for setup and usage.\n\n### 4. Statistical Tools\n\nExecute code with various inputs, measure elapsed time, and detect inconsistencies. Tests actual implementation including compiler optimizations and architecture.\n\n**Popular tools:**\n- **dudect** (see below)\n- [tlsfuzzer](https:\u002F\u002Fgithub.com\u002Ftlsfuzzer\u002Ftlsfuzzer)\n\n**Strengths:** Simple setup, practical real-world results\n**Weaknesses:** No root cause info, noise obscures weak signals\n\n> **Detailed Guidance:** See the **dudect** skill for setup and usage.\n\n## Testing Workflow\n\n```\nPhase 1: Static Analysis        Phase 2: Statistical Testing\n┌─────────────────┐            ┌─────────────────┐\n│ Identify secret │      →     │ Detect timing   │\n│ data flow       │            │ differences     │\n│ Tool: ct-verif  │            │ Tool: dudect    │\n└─────────────────┘            └─────────────────┘\n         ↓                              ↓\nPhase 4: Root Cause             Phase 3: Dynamic Tracing\n┌─────────────────┐            ┌─────────────────┐\n│ Pinpoint leak   │      ←     │ Track secret    │\n│ location        │            │ propagation     │\n│ Tool: Timecop   │            │ Tool: Timecop   │\n└─────────────────┘            └─────────────────┘\n```\n\n**Recommended approach:**\n1. **Start with dudect** - Quick statistical check for timing differences\n2. **If leaks found** - Use Timecop to pinpoint root cause\n3. **For high-assurance** - Apply formal verification (ct-verif, SideTrail)\n4. **Continuous monitoring** - Integrate dudect into CI pipeline\n\n## Tools and Approaches\n\n### Dudect - Statistical Analysis\n\n[Dudect](https:\u002F\u002Fgithub.com\u002Foreparaz\u002Fdudect\u002F) measures execution time for two input classes (fixed vs random) and uses Welch's t-test to detect statistically significant differences.\n\n> **Detailed Guidance:** See the **dudect** skill for complete setup, usage patterns, and CI integration.\n\n#### Quick Start for Constant-Time Analysis\n\n```c\n#define DUDECT_IMPLEMENTATION\n#include \"dudect.h\"\n\nuint8_t do_one_computation(uint8_t *data) {\n    \u002F\u002F Code to measure goes here\n}\n\nvoid prepare_inputs(dudect_config_t *c, uint8_t *input_data, uint8_t *classes) {\n    for (size_t i = 0; i \u003C c->number_measurements; i++) {\n        classes[i] = randombit();\n        uint8_t *input = input_data + (size_t)i * c->chunk_size;\n        if (classes[i] == 0) {\n            \u002F\u002F Fixed input class\n        } else {\n            \u002F\u002F Random input class\n        }\n    }\n}\n```\n\n**Key advantages:**\n- Simple C header-only integration\n- Statistical rigor via Welch's t-test\n- Works with compiled binaries (real-world conditions)\n\n**Key limitations:**\n- No root cause information when leak detected\n- Sensitive to measurement noise\n- Cannot guarantee absence of leaks (statistical confidence only)\n\n### Timecop - Dynamic Tracing\n\n[Timecop](https:\u002F\u002Fpost-apocalyptic-crypto.org\u002Ftimecop\u002F) wraps Valgrind to detect runtime operations dependent on secret memory regions.\n\n> **Detailed Guidance:** See the **timecop** skill for installation, examples, and debugging.\n\n#### Quick Start for Constant-Time Analysis\n\n```c\n#include \"valgrind\u002Fmemcheck.h\"\n\n#define poison(addr, len) VALGRIND_MAKE_MEM_UNDEFINED(addr, len)\n#define unpoison(addr, len) VALGRIND_MAKE_MEM_DEFINED(addr, len)\n\nint main() {\n    unsigned long long secret_key = 0x12345678;\n\n    \u002F\u002F Mark secret as poisoned\n    poison(&secret_key, sizeof(secret_key));\n\n    \u002F\u002F Any branching or memory access dependent on secret_key\n    \u002F\u002F will be reported by Valgrind\n    crypto_operation(secret_key);\n\n    unpoison(&secret_key, sizeof(secret_key));\n}\n```\n\nRun with Valgrind:\n```bash\nvalgrind --leak-check=full --track-origins=yes .\u002Fbinary\n```\n\n**Key advantages:**\n- Pinpoints exact line of timing leak\n- No code instrumentation required\n- Tracks secret propagation through execution\n\n**Key limitations:**\n- Cannot detect microarchitecture timing differences\n- Coverage limited to executed paths\n- Performance overhead (runs on synthetic CPU)\n\n## Implementation Guide\n\n### Phase 1: Initial Assessment\n\n**Identify cryptographic code handling secrets:**\n- Private keys, exponents, nonces\n- Password hashes, authentication tokens\n- Encryption\u002Fdecryption operations\n\n**Quick statistical check:**\n1. Write dudect harness for the crypto function\n2. Run for 5-10 minutes with `timeout 600 .\u002Fct_test`\n3. Monitor t-value: high absolute values indicate leakage\n\n**Tools:** dudect\n**Expected time:** 1-2 hours (harness writing + initial run)\n\n### Phase 2: Detailed Analysis\n\nIf dudect detects leakage:\n\n**Root cause investigation:**\n1. Mark secret variables with Timecop `poison()`\n2. Run under Valgrind to identify exact line\n3. Review the four common violation patterns\n4. Check assembly output for conditional branches\n\n**Tools:** Timecop, compiler output (`objdump -d`)\n\n### Phase 3: Remediation\n\n**Fix the timing leak:**\n- Replace conditional branches with constant-time selection (bitwise operations)\n- Use constant-time comparison functions\n- Replace array lookups with constant-time alternatives or masking\n- Verify compiler doesn't optimize away constant-time code\n\n**Re-verify:**\n1. Run dudect again for extended period (30+ minutes)\n2. Test across different compilers and optimization levels\n3. Test on different CPU architectures\n\n### Phase 4: Continuous Monitoring\n\n**Integrate into CI:**\n- Add dudect tests to test suite\n- Run for fixed duration (5-10 minutes in CI)\n- Fail build if leakage detected\n\nSee the **dudect** skill for CI integration examples.\n\n## Common Vulnerabilities\n\n| Vulnerability | Description | Detection | Severity |\n|---------------|-------------|-----------|----------|\n| Secret-dependent branch | `if (secret_bit) { ... }` | dudect, Timecop | CRITICAL |\n| Secret-dependent array access | `table[secret_index]` | Timecop, Binsec | HIGH |\n| Variable-time division | `result = x \u002F secret` | Timecop | MEDIUM |\n| Variable-time shift | `result = x \u003C\u003C secret` | Timecop | MEDIUM |\n| Montgomery reduction leak | Extra reduction when intermediate > N | dudect | HIGH |\n\n### Secret-Dependent Branch: Deep Dive\n\n**The vulnerability:**\nExecution time differs based on whether branch is taken. Common in optimized modular exponentiation (square-and-multiply).\n\n**How to detect with dudect:**\n```c\nuint8_t do_one_computation(uint8_t *data) {\n    uint64_t base = ((uint64_t*)data)[0];\n    uint64_t exponent = ((uint64_t*)data)[1]; \u002F\u002F Secret!\n    return mod_exp(base, exponent, MODULUS);\n}\n\nvoid prepare_inputs(dudect_config_t *c, uint8_t *input_data, uint8_t *classes) {\n    for (size_t i = 0; i \u003C c->number_measurements; i++) {\n        classes[i] = randombit();\n        uint64_t *input = (uint64_t*)(input_data + i * c->chunk_size);\n        input[0] = rand(); \u002F\u002F Random base\n        input[1] = (classes[i] == 0) ? FIXED_EXPONENT : rand(); \u002F\u002F Fixed vs random\n    }\n}\n```\n\n**How to detect with Timecop:**\n```c\npoison(&exponent, sizeof(exponent));\nresult = mod_exp(base, exponent, modulus);\nunpoison(&exponent, sizeof(exponent));\n```\n\nValgrind will report:\n```\nConditional jump or move depends on uninitialised value(s)\n  at 0x40115D: mod_exp (example.c:14)\n```\n\n**Related skill:** **dudect**, **timecop**\n\n## Case Studies\n\n### Case Study: OpenSSL RSA Timing Attack\n\nBrumley and Boneh (2005) extracted RSA private keys from OpenSSL over a network. The vulnerability exploited Montgomery multiplication's variable-time reduction step.\n\n**Attack vector:** Timing differences in modular exponentiation\n**Detection approach:** Statistical analysis (precursor to dudect)\n**Impact:** Remote key extraction\n\n**Tools used:** Custom timing measurement\n**Techniques applied:** Statistical analysis, chosen-ciphertext queries\n\n### Case Study: KyberSlash\n\nPost-quantum algorithm Kyber's reference implementation contained timing vulnerabilities in polynomial operations. Division operations leaked secret coefficients.\n\n**Attack vector:** Secret-dependent division timing\n**Detection approach:** Dynamic analysis and statistical testing\n**Impact:** Secret key recovery in post-quantum cryptography\n\n**Tools used:** Timing measurement tools\n**Techniques applied:** Differential timing analysis\n\n## Advanced Usage\n\n### Tips and Tricks\n\n| Tip | Why It Helps |\n|-----|--------------|\n| Pin dudect to isolated CPU core (`taskset -c 2`) | Reduces OS noise, improves signal detection |\n| Test multiple compilers (gcc, clang, MSVC) | Optimizations may introduce or remove leaks |\n| Run dudect for extended periods (hours) | Increases statistical confidence |\n| Minimize non-crypto code in harness | Reduces noise that masks weak signals |\n| Check assembly output (`objdump -d`) | Verify compiler didn't introduce branches |\n| Use `-O3 -march=native` in testing | Matches production optimization levels |\n\n### Common Mistakes\n\n| Mistake | Why It's Wrong | Correct Approach |\n|---------|----------------|------------------|\n| Only testing one input distribution | May miss leaks visible with other patterns | Test fixed-vs-random, fixed-vs-fixed-different, etc. |\n| Short dudect runs (\u003C 1 minute) | Insufficient measurements for weak signals | Run 5-10+ minutes, longer for high assurance |\n| Ignoring compiler optimization levels | `-O0` may hide leaks present in `-O3` | Test at production optimization level |\n| Not testing on target architecture | x86 vs ARM have different timing characteristics | Test on deployment platform |\n| Marking too much as secret in Timecop | False positives, unclear results | Mark only true secrets (keys, not public data) |\n\n## Related Skills\n\n### Tool Skills\n\n| Skill | Primary Use in Constant-Time Analysis |\n|-------|---------------------------------------|\n| **dudect** | Statistical detection of timing differences via Welch's t-test |\n| **timecop** | Dynamic tracing to pinpoint exact location of timing leaks |\n\n### Technique Skills\n\n| Skill | When to Apply |\n|-------|---------------|\n| **coverage-analysis** | Ensure test inputs exercise all code paths in crypto function |\n| **ci-integration** | Automate constant-time testing in continuous integration pipeline |\n\n### Related Domain Skills\n\n| Skill | Relationship |\n|-------|--------------|\n| **crypto-testing** | Constant-time analysis is essential component of cryptographic testing |\n| **fuzzing** | Fuzzing crypto code may trigger timing-dependent paths |\n\n## Skill Dependency Map\n\n```\n                    ┌─────────────────────────┐\n                    │  constant-time-analysis │\n                    │     (this skill)        │\n                    └───────────┬─────────────┘\n                                │\n                ┌───────────────┴───────────────┐\n                │                               │\n                ▼                               ▼\n    ┌───────────────────┐           ┌───────────────────┐\n    │      dudect       │           │     timecop       │\n    │  (statistical)    │           │    (dynamic)      │\n    └────────┬──────────┘           └────────┬──────────┘\n             │                               │\n             └───────────────┬───────────────┘\n                             │\n                             ▼\n              ┌──────────────────────────────┐\n              │   Supporting Techniques      │\n              │ coverage, CI integration     │\n              └──────────────────────────────┘\n```\n\n## Resources\n\n### Key External Resources\n\n**[These results must be false: A usability evaluation of constant-time analysis tools](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fsec24fall-prepub-760-fourne.pdf)**\nComprehensive usability study of constant-time analysis tools. Key findings: developers struggle with false positives, need better error messages, and benefit from tool integration. Evaluates FaCT, ct-verif, dudect, and Memsan across multiple cryptographic implementations. Recommends improved tooling UX and better documentation.\n\n**[List of constant-time tools - CROCS](https:\u002F\u002Fcrocs-muni.github.io\u002Fct-tools\u002F)**\nCurated catalog of constant-time analysis tools with tutorials. Covers formal tools (ct-verif, FaCT), dynamic tools (Memsan, Timecop), symbolic tools (Binsec), and statistical tools (dudect). Includes practical tutorials for setup and usage.\n\n**[Paul Kocher: Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems](https:\u002F\u002Fpaulkocher.com\u002Fdoc\u002FTimingAttacks.pdf)**\nOriginal 1996 paper introducing timing attacks. Demonstrates attacks on modular exponentiation in RSA and Diffie-Hellman. Essential historical context for understanding timing vulnerabilities.\n\n**[Remote Timing Attacks are Practical (Brumley & Boneh)](https:\u002F\u002Fcrypto.stanford.edu\u002F~dabo\u002Fpapers\u002Fssl-timing.pdf)**\nDemonstrates practical remote timing attacks against OpenSSL. Shows network-level timing differences are sufficient to extract RSA keys. Proves timing attacks work in realistic network conditions.\n\n**[Cache-timing attacks on AES](https:\u002F\u002Fcr.yp.to\u002Fantiforgery\u002Fcachetiming-20050414.pdf)**\nShows AES implementations using lookup tables are vulnerable to cache-timing attacks. Demonstrates practical attacks extracting AES keys via cache timing side channels.\n\n**[KyberSlash: Division Timings Leak Secrets](https:\u002F\u002Feprint.iacr.org\u002F2024\u002F1049.pdf)**\nRecent discovery of timing vulnerabilities in Kyber (NIST post-quantum standard). Shows division operations leak secret coefficients. Highlights that constant-time issues persist even in modern post-quantum cryptography.\n\n### Video Resources\n\n- [Trail of Bits: Constant-Time Programming](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=vW6wqTzfz5g) - Overview of constant-time programming principles and tools\n",{"name":5,"type":30,"description":7},"master","c73386b305dec167db7654e0e6feacb462d4f9dc","assets\u002Fskills\u002Fsecurity\u002Fconstant-time-testing",1,"https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code","https:\u002F\u002Fgithub.com\u002FAntifragileTech","2026-10-02 14:22:14",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add AntifragileTech\u002Fantifragile-claude-code --skill constant-time-testing",{"tool":49,"command":50},"bunx","bunx skills add AntifragileTech\u002Fantifragile-claude-code --skill constant-time-testing",{"tool":52,"command":53},"pnpm","pnpm dlx skills add AntifragileTech\u002Fantifragile-claude-code --skill constant-time-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fsecurity\u002Fconstant-time-testing\u002FSKILL.md",true,[],[58,79,93,108,121,134],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":73,"publishedAt":31},"01M6DT9Q6VYA615SCXR757TZZ7","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-skills\u002FSKILL.md",[64,65,68],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":66,"categoryName":67,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[74,75,28,76,77,78],"writing skills","writing","editing","work","deployment",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":87,"publishedAt":31},"01M6DT9GFHDNY90P41WGAE1TV0","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-plans\u002FSKILL.md",[85,86],{"categoryNo":66,"categoryName":67,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[88,89,75,90,91,28,27,92],"plans","writing plans","requirements","task","spec",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":101,"publishedAt":31},"01M6DT9C6PFGD86WS3HY7YE3XG","docs:write-concisely","Apply writing rules to any documentation that humans will read. Makes your writing clearer, stronger, and more professional.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwrite-concisely\u002FSKILL.md",[99,100],{"categoryNo":66,"categoryName":67,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[102,103,104,105,106,107,75],"docs:write concisely","write","docs","read","Rules","documentation",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":31},"01M6DT98AWQ27P0N1CG97WAG66","kaizen:why","Iterative Five Whys root cause analysis drilling from symptoms to fundamentals","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwhy\u002FSKILL.md",[],[110,115,116,117,118,119,120],"why","kaizen","issue","five whys","analysis","root cause analysis",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":31},"01M6DT93EH25NAX19R3WGE1P53","verification-loop","A comprehensive verification system for Claude Code sessions.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-loop\u002FSKILL.md",[],[128,129,130,131,27,132,133],"verification loop","verification","loop","sessions","claude code sessions","system",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":31},"01M6DT90GW7Z7VCN98P9DVYSNC","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-before-completion\u002FSKILL.md",[],[141,129,142,77,28,143,144,145],"verification before completion","commands","evidence","claim","complete"]