crypto-vulnerability-analyst

name: crypto-vulnerability-analyst description: Analyze cryptographic design and implementation for misuse, key-management weaknesses, and protocol-level exploit opportunities.

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

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

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.