skills/1ikeadragon/awesome-offsec-claude/crypto-vulnerability-analyst

crypto-vulnerability-analyst

SKILL.md

Crypto Vulnerability Analyst

Purpose

Find exploitable cryptographic weakness across primitive choice, implementation details, and protocol flow.

Inputs

  • code_or_binary_context
  • protocol_description
  • key_management_model

Workflow

Phase 1: Crypto Inventory

  1. Identify algorithms, modes, and libraries.
  2. Identify key derivation and randomness sources.
  3. Identify trust anchors and certificate behavior.

Phase 2: Misuse Detection

  1. Nonce/IV reuse or predictability.
  2. Weak or obsolete algorithms/modes.
  3. Insecure comparisons and padding issues.
  4. Missing authenticity or misuse of MAC/AEAD.

Phase 3: Key Lifecycle Review

  1. Key generation entropy quality.
  2. Key storage and exposure paths.
  3. Rotation, revocation, and scope boundaries.

Phase 4: Protocol Attack Analysis

  1. Replay and reflection opportunities.
  2. Downgrade and negotiation weaknesses.
  3. Oracle-like behavior from error distinctions.

Phase 5: Risk and Fix Prioritization

  1. Separate compliance issues from exploitable flaws.
  2. Prioritize fixes by exploit practicality.
  3. Provide migration-safe remediation guidance.

Crypto Assessment Matrix

Area Failure Pattern
encryption unauthenticated encryption for sensitive state
key management shared static keys across tenants/environments
randomness predictable nonce/session token generation
protocol downgrade and replay not cryptographically bound

Output Contract

{
  "crypto_inventory": [],
  "misuse_findings": [],
  "protocol_risks": [],
  "key_management_gaps": [],
  "prioritized_remediation": []
}

Constraints

  • Do not equate deprecated with exploitable without context.
  • Clearly label confidence when implementation visibility is partial.

Quality Checklist

  • Primitive and mode details are explicit.
  • Exploit path is technically plausible.
  • Remediation is concrete.

Detailed Operator Notes

Validation Discipline

  • Confirm static assumptions with targeted runtime checks.
  • Keep one controlled input per hypothesis.
  • Separate symbol-level hints from observed behavior.

Exploitability Heuristics

  • Control quality over corrupted bytes/pointers.
  • Trigger repeatability across process restarts.
  • Mitigation interaction required for practical exploitation.

Common Blind Spots

  • Architecture-specific undefined behavior differences.
  • Parser edge cases reachable only through nested formats.
  • Configuration-dependent code paths not visible in default runs.

Reporting Rules

  • Include prerequisite runtime conditions.
  • Include why alternative bug classes were rejected.
  • Include a minimal regression-test suggestion for remediation.

Quick Scenarios

Scenario A: Control Validation

  • Trigger candidate primitive with minimal input.
  • Confirm memory/register side effect.
  • Repeat across restarts for stability.
  • Record constraints that break control.

Scenario B: Mitigation Interaction

  • Confirm active hardening controls.
  • Test whether primitive survives mitigations.
  • Distinguish crash-only from exploit-capable outcomes.
  • Capture bypass requirements if needed.

Scenario C: Reporting Readiness

  • Verify prerequisite environment notes.
  • Verify reproduction steps are deterministic.
  • Verify impact statement is evidence-bound.
  • Verify remediation target is specific.

Conditional Decision Matrix

Condition Action Evidence Requirement
Crash reproduces inconsistently reduce input and isolate triggering fields minimal trigger artifact
Primitive appears but control unclear instrument memory/register checkpoints control-surface trace
Mitigation blocks direct exploitation model required bypass preconditions mitigation interaction notes
Parser path uncertain force parser branch with crafted corpus branch-selection evidence
Static finding lacks runtime proof add targeted runtime probe before reporting runtime validation artifact

Advanced Coverage Extensions

  1. Compare behavior across compiler optimization levels when possible.
  2. Check locale/encoding effects on parser and boundary logic.
  3. Check integer truncation across 32/64-bit interfaces.
  4. Check allocator behavior differences under memory pressure.
  5. Check cryptographic error oracles via differential response paths.
Weekly Installs
2
GitHub Stars
4
First Seen
Mar 2, 2026
Installed on
amp2
cline2
opencode2
cursor2
kimi-cli2
codex2