constant-time-analysis

Overview of constant-time-analysis skill

constant-time-analysis is a security-audit skill for finding timing side-channel risks in crypto code before they become exploitable bugs. It is best for engineers, reviewers, and AI agents checking whether secret-dependent math, branches, comparisons, or runtime instructions could leak keys, tokens, or other sensitive values.

The main job-to-be-done is not “understand crypto theory” but “spot where this code stops being constant-time.” That makes the constant-time-analysis skill most useful during implementation reviews, pre-merge security checks, and incident triage when someone asks whether a function is safe against timing attacks.

What differentiates it from a generic prompt is that it is built around compiled output and language-specific analysis paths, not just source scanning. That matters because constant-time problems often show up in assembly, bytecode, or VM instructions even when source code looks harmless.

Best fit for constant-time-analysis for Security Audit

Use this skill when you are reviewing code that:

• handles secrets, authentication, or cryptographic primitives
• uses division, modulo, comparison, or branching on secret-derived values
• needs validation across compiled artifacts, not just source intent
• targets C, C++, Go, Rust, Swift, Java, Kotlin, PHP, JavaScript, TypeScript, Python, or Ruby

What it catches and what it misses

constant-time-analysis is strong for timing-leak patterns such as variable-time division, secret-dependent branches, and unsafe comparisons. It is weaker for broader cryptographic design mistakes, protocol flaws, or leaks that come from networking, caching, or environment noise unless those issues appear in the analyzed code path.

Why users install it

Install this skill when you want a repeatable review workflow that can flag timing risk earlier than a manual skim. If you only need a one-off opinion on a single snippet, a plain prompt may be enough; if you need consistent security review behavior, the skill adds structure.

How to Use constant-time-analysis skill

Install and trigger it correctly

Use the constant-time-analysis install path from your skill manager, then run it in a context that includes the target language and the sensitive function or file. A good trigger prompt names the crypto goal, the secret inputs, and the language/runtime so the skill can choose the right analysis path.

Example trigger:

• “Review src/sign.rs for constant-time risk. Secret input is the private key scalar; focus on division, branches, and comparisons.”
• “Run constant-time-analysis on this PHP password-checking function and tell me whether any opcode-level timing leak is likely.”

Give the skill the right input shape

The skill works best when you provide:

• the file or function to inspect
• which values are secret
• what attacker-visible behavior matters
• the target language and runtime version if known

Better input:

• “Audit verifyToken() in TypeScript. Token bytes are secret; compare against stored HMAC; check for Div, Mod, and early-exit comparisons.”
• “Analyze this Rust reduce() routine for secret-dependent division across x86_64 and arm64.”

Read these files first

For install decisions and workflow, start with:

• SKILL.md for triggers, scope, and language selection
• README.md for supported languages and output goals
• references/compiled.md for C/C++, Go, and Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md for VM-specific rules

If you only skim one reference file, pick the one matching your runtime path rather than your source language label.

Use a review workflow, not a single pass

A practical constant-time-analysis usage flow is:

1. identify the secret-bearing function
2. run the appropriate language guide
3. inspect any division, modulo, comparisons, branches, or suspicious helper calls
4. re-run after refactoring or compiler/runtime changes
5. request CI-friendly output if you want the result machine-checked

This matters because a fix in source can still compile into unsafe instructions, especially in compiled languages.

constant-time-analysis skill FAQ

Is constant-time-analysis only for cryptography?

No. It is for any code where timing differences on secret data matter, but that usually means crypto, auth, key handling, and token verification. If the code processes only public data, the skill is probably unnecessary.

Do I need assembly or bytecode expertise?

Not to start. The skill is useful precisely because it points you toward the right runtime artifact and language-specific reference. You do not need to read every instruction, but you do need to know which function or file is security-sensitive.

Is constant-time-analysis better than a normal prompt?

Yes, when you need repeatable security review behavior. A normal prompt can identify obvious risks, but constant-time-analysis is more useful for repository work because it is organized around language selection, compiled output, and concrete leak patterns.

When should I not use it?

Do not use it for ordinary business logic, UI code, or public-data transformations. Also skip it when the library already guarantees constant-time behavior and you are only asking about high-level API usage without custom secret-dependent logic.

How to Improve constant-time-analysis skill

Focus on the secret and the attacker model

The strongest constant-time-analysis results come from naming exactly what must stay secret and what the attacker can observe. Say whether the risk is remote timing, local process timing, or compiled-code inspection. Without that, the skill may over-focus on harmless branches or miss the real constraint.

Provide the smallest risky code path

Give the function that actually touches secret data, not the whole repository. If the path includes helpers, include them only when they influence branching, arithmetic, or comparisons. This reduces noise and makes the output easier to act on.

Ask for language-specific evidence

For best results, ask the skill to check the relevant runtime artifact:

• assembly for C/C++, Go, Rust
• bytecode for JavaScript, TypeScript, Python, Ruby, PHP
• JVM behavior for Kotlin

That improves constant-time-analysis usage because timing leaks often emerge below the source level.

Re-run after each fix

A common failure mode is fixing source code and assuming the leak is gone. Re-test after changing the algorithm, compiler flags, optimization level, or runtime version. For constant-time-analysis for Security Audit, that second pass is often where you confirm the real security posture.