Cryptographer Specialist

Cryptographer Specialist

When to Use

• Select and justify cryptographic primitives (AEAD, signatures, KEMs, hashes, KDFs)
• Design key lifecycle — generation, storage, rotation, escrow policy, destruction, dual control
• Architect PKI and TLS — internal CAs, cert profiles, mTLS, pinning, stapling, cipher policies
• Review protocols — handshakes, transcript binding, downgrade resistance, session keys
• Analyze authenticated encryption misuse — nonces, IVs, associated data, key separation
• Compare password hashing (Argon2, bcrypt, scrypt) vs KDFs (HKDF, PBKDF2) for the use case
• Plan post-quantum awareness — hybrid schemes, inventory, migration sequencing (architecture level)
• Frame formal properties — secrecy, authentication, forward secrecy, agreement (ProVerif/Tamarin concepts)
• Specify implementation requirements — constant-time, zeroization, entropy, crypto agility
• Produce crypto design reviews and threat-informed recommendations with explicit assumptions

When NOT to Use

• General OWASP web/API pentest or app-layer vuln triage without crypto design → information-security-engineer, web-pentester, penetration-tester
• Broad secure-coding review across stacks (injection, authz, headers) without primitive/protocol focus → use secure-coding skills in the agent catalog (e.g. code-security when installed)
• Deploy SIEM, IdP, EDR, or corp guardrails without cryptographic design → information-security-engineer
• Solidity/EVM smart contract audit or DeFi on-chain triage → evm-solidity-defi-triage-agent (agent skill) or protocol-specific audit skills
• Blockchain address tracing, clustering, or compliance screening → blockint / on-chain investigation skills
• Legal export control, sanctions, or jurisdiction classification → commercial-counsel (legal boundaries only; not legal advice)
• Implement a full production crypto library from scratch without peer review, standards alignment, and test vectors
• ML adversarial robustness on models → ai-adversarial-robustness-engineer
• Assurance cases and DO-178C-style software assurance without crypto-specific claims → software-assurance-formal-methods-specialist

Related skills

Core Workflows

1. Scope and assets

1. Identify protected assets (keys, plaintext, metadata, identities, logs) 2. Define adversary model — network, insider, physical, quantum timeline 3. List trust boundaries and assumptions (HSM, OS RNG, third-party libraries) 4. Record compliance or policy constraints (FIPS, regional, customer crypto profiles)

See `references/cryptographer_specialist_scope.md`.

2. Primitive and algorithm selection

Map security goals to approved primitive families; document tradeoffs and deprecation status.

See `references/primitives_and_algorithm_selection.md`.

3. Key management, PKI, and TLS

Design key hierarchy, rotation, escrow exceptions, and certificate/TLS profiles.

See `references/key_management_pki_and_tls.md`.

4. Protocol design and security properties

Specify messages, key derivation, binding, and the properties each layer must achieve.

See `references/protocol_design_and_properties.md`.

5. Implementation pitfalls and side channels

Translate design into developer requirements: AEAD usage, timing, memory, RNG, error handling.

See `references/implementation_pitfalls_and_side_channels.md`.

6. Formal methods, agility, and governance

Align with verification artifacts, algorithm sunset, and review gates for crypto changes.

See `references/formal_methods_agility_governance.md`.

Outputs

• Crypto design note — goals, primitives, key sizes, lifetimes, assumptions, open risks
• Protocol review — message flow, derived keys, downgrade and replay analysis
• TLS/PKI profile — versions, cipher suites, cert fields, rotation, monitoring
• Implementation checklist — nonce rules, constant-time surfaces, zeroization, test vectors
• Migration plan — deprecated algorithms, PQ hybrid options, inventory and phases
• Formal-methods brief — intended properties, model scope, tool fit (when applicable)

Principles

• Prefer well-vetted libraries and standards (RFCs, NIST, CFRG) over custom constructions
• Never roll your own block cipher, hash, or protocol; compose proven building blocks
• Separate confidentiality, integrity, and identity keys; document nonce uniqueness rules
• Treat password hashing and key derivation as different problems with different parameters
• Plan crypto agility before algorithms break; monitor deprecations (SHA-1, RSA-1024, TLS 1.0/1.1)
• Escalate legal/export questions to counsel; do not provide export classification advice

When to load references

• Scope and boundaries → references/cryptographer_specialist_scope.md
• Algorithms and primitives → references/primitives_and_algorithm_selection.md
• Keys, PKI, TLS → references/key_management_pki_and_tls.md
• Protocols and properties → references/protocol_design_and_properties.md
• Implementation and side channels → references/implementation_pitfalls_and_side_channels.md
• Formal methods and governance → references/formal_methods_agility_governance.md

Cryptographer specialist scope

Table of contents

1. Purpose 2. In scope 3. Out of scope 4. Adversary and trust models 5. Deliverables 6. Engagement checklist

Purpose

Provide cryptographic design, analysis, and protocol guidance—selecting primitives, defining key lifecycles, reviewing handshakes and message formats, and specifying implementation constraints. Work is architecture- and design-centric, not a substitute for authorized penetration testing or legal export advice.

In scope

Out of scope

• General AppSec without cryptographic design (XSS, SQLi, authz bugs) unless they intersect key material
• Smart contract Solidity audits and on-chain economic exploits
• Blockchain tracing, clustering, sanctions screening
• Legal export control classification or jurisdiction determinations
• Building production crypto libraries from scratch without standards alignment and independent review
• SOC operations, SIEM tuning, or corporate IdP rollout (unless crypto parameters are in question)

Adversary and trust models

Document explicitly for each engagement:

Assumptions must be listed (e.g., "TLS terminator is trusted," "client stores long-term key in secure enclave"). Invalid assumptions invalidate the design.

Deliverables

1. Crypto design note — goals, chosen primitives, key sizes, lifetimes, rationale, residual risks 2. Threat-informed protocol review — flows, derived keys, binding, known attack classes considered 3. TLS/PKI profile — versions, suites, cert fields, validity, renewal, monitoring alerts 4. Implementation requirements — nonce rules, AD handling, constant-time surfaces, test vector references 5. Migration roadmap (when needed) — inventory, phases, hybrid PQ options, rollback criteria 6. Formal-methods brief (optional) — properties, model scope, tool choice, limitations

Engagement checklist

1. Confirm authorization for review (design doc, code, configs)—no production key extraction 2. Identify data classification and regulatory drivers (FIPS 140, PCI, customer crypto addenda) 3. List existing standards the org must follow (internal crypto standards, customer requirements) 4. Capture interoperability constraints (legacy clients, hardware tokens, FIPS-only modules) 5. Agree review depth — design-only vs config review vs targeted code paths 6. Define success criteria — e.g., "TLS 1.2+ only," "no nonce reuse possible by API contract" 7. Route legal/export questions to counsel; flag dual-use or classified contexts early 8. Schedule follow-up for agility (deprecation calendar) and post-implementation verification

Formal methods, agility, and governance

Table of contents

1. Crypto governance 2. Approved algorithms and exceptions 3. Crypto agility 4. Deprecation program 5. Formal methods workflow 6. ProVerif and Tamarin concepts 7. Change control and evidence 8. Legal and export boundaries

Crypto governance

Establish organizational control without blocking delivery:

Review triggers: new protocol, custom KDF, change to root CA, new HSM policy, customer crypto addendum, post-incident crypto failure.

Approved algorithms and exceptions

Maintain a living approved list synced with primitives_and_algorithm_selection.md:

• Symmetric, hash, signature, KEM, password, KDF columns
• Sunset date per deprecated entry
• FIPS / regional columns (e.g., EU, federal)

Exception process:

1. Business justification and risk owner 2. Compensating controls (network isolation, shortened lifetime, monitoring) 3. Expiry date and remediation ticket 4. Executive or CISO delegate approval for high risk

Crypto agility

Design systems to swap algorithms without rewriting applications:

Inventory fields: algorithm, key ID, location, owner, last rotation, PQ sensitivity (HNDL).

Test rollback of agility changes in staging before production.

Deprecation program

Priority deprecations: SHA-1 signatures, RSA-1024, TLS 1.0/1.1, weak DH (<2048), RC4/3DES, CBC without MAC discipline.

Formal methods workflow

When to invest:

• High-impact protocol (auth, payments, key enrollment)
• Prior incidents or subtle race/replay bugs
• Regulatory or customer demand for assurance evidence

Steps:

1. Freeze protocol narrative and assumptions 2. Build abstract model (roles, channels, crypto as equations) 3. State queries (secrecy, authentication, equivalence) 4. Run tool; analyze counterexamples → fix spec or design 5. Map model elements to implementation (gap analysis) 6. Archive model + scripts in version control

Limitation: symbolic models ≠ timing, memory, or implementation bugs—pair with code review and testing.

ProVerif and Tamarin concepts

ProVerif:

• Processes, channels, cryptography as perfect or symbolic
• Queries: query attacker(s) for secrecy; event() implications for authentication
• Good for large protocol skeletons and standard primitives

Tamarin:

• Multiset rewriting rules; support for equational theories (Diffie-Hellman)
• Strong for stateful protocols, compromise models, complex induction

Shared vocabulary:

• Dolev-Yao attacker controls network
• Corruption queries (reveal long-term key) test forward secrecy
• Observational equivalence for privacy (vote, anonymity)

Integrate with mermaid-to-proverif and crypto-protocol-diagram (agent catalog) for diagram-driven workflows.

Change control and evidence

For each crypto change, retain:

• Design doc and threat model delta
• Review sign-off (cryptographer + implementer)
• Test results (unit, Wycheproof, TLS scan)
• Config diffs (cipher suites, cert templates)
• Rollback plan

Link to assurance cases when software-assurance-formal-methods-specialist applies (safety-critical or certified products).

Legal and export boundaries

• Do not provide export classification, deemed export, or sanctions determinations
• Flag designs involving dual-use crypto, classified environments, or cross-border key escrow to legal/compliance
• Route contract clauses on crypto obligations to commercial-counsel (legal review—not legal advice from the agent)

Document customer contractual crypto requirements separately from engineering standards.

Implementation pitfalls and side channels

Table of contents

1. AEAD and nonce discipline 2. API design mistakes 3. Randomness and entropy 4. Constant-time and side channels 5. Memory and zeroization 6. Error handling and oracle attacks 7. Library and dependency hygiene 8. Verification checklist

AEAD and nonce discipline

AES-GCM / ChaCha20-Poly1305:

• Never reuse (key, nonce) — disclosure of plaintext and forgery keys possible (GCM)
• Prefer random 96-bit nonce per message under a random key, or counter with partition per sender
• Document max messages per key before rotation (GCM volume limits ~2^32 blocks with same key in some policies)

Associated data (AAD):

• Authenticate version, type, length, context in AAD when not inside ciphertext
• Keep AAD canonical (stable encoding) to avoid ambiguity attacks

Key separation:

• Distinct keys for encrypt vs MAC vs IV generation when not using integrated AEAD
• Do not derive all keys from one hash output without HKDF labels

API design mistakes

Randomness and entropy

• Use OS CSPRNG (getrandom, BCryptGenRandom, crypto/rand)
• Seed userspace DRBG from OS only; do not seed from time/PID alone
• Tokens: at least 128 bits entropy; use URL-safe encoding without shortening
• Key generation: in HSM/KMS when policy requires; log generation events

Failures: VM clone without fresh seed, embedded devices without hardware RNG—require health checks.

Constant-time and side channels

Threat: attacker measures time, cache, or power to infer secrets.

High-risk operations:

• Private key operations (RSA, ECDSA)
• AES key schedule on secret keys (less issue with AES-NI bulk)
• Comparison of MACs/passwords
• Branching on secret-dependent memory indices

Mitigations:

• Use libraries with constant-time implementations (libsodium, BearSSL patterns, verified builds)
• Avoid secret-dependent branches in custom code
• Prefer Ed25519/X25519 over RSA where possible for performance and timing
• Isolate crypto in separate process/HSM for high-value keys

Use constant-time-analysis and constant-time-testing (agent catalog) for targeted audits.

Memory and zeroization

• Zero stack buffers holding keys/passwords after use where language allows
• Avoid swapping sensitive pages where possible (mlock—platform specific, operational tradeoff)
• Prevent keys in core dumps and crash reports
• Clear String objects that held passwords (language-dependent; prefer byte arrays)

Use zeroize-audit (agent catalog) for C/C++/Rust secret lifecycle reviews.

Error handling and oracle attacks

Rule: return one client-visible error for auth/decrypt failures; log details server-side with correlation ID.

Library and dependency hygiene

• Pin versions of crypto libraries; monitor CVEs (OpenSSL, BoringSSL, mbedTLS, etc.)
• Enable FIPS mode only when required—understand algorithm restrictions
• Disable legacy providers in OpenSSL 3.x where possible
• Do not fork boring crypto snippets from Stack Overflow
• Run known-answer tests and Wycheproof vectors where available

Verification checklist

Before release of crypto-touching code:

• [ ] Nonce/uniqueness rules documented and enforced in API
• [ ] No secret branches or early returns on failed MAC compare
• [ ] Keys only in KMS/HSM or sealed config—not repos
• [ ] TLS config scanned; certs monitored
• [ ] Test vectors from RFCs or Wycheproof for parsers and edge cases
• [ ] Threat model updated if protocol fields changed
• [ ] Peer review by second engineer with crypto literacy
• [ ] Fuzzing on decoders (length fields, ASN.1) where applicable

Key management, PKI, and TLS

Table of contents

1. Key hierarchy 2. Generation and storage 3. Rotation and lifecycle 4. Escrow and recovery 5. HSM and KMS patterns 6. PKI architecture 7. TLS configuration 8. Monitoring and incident response

Key hierarchy

Typical layers:

root CA (offline) → issuing CA / intermediate → end-entity certs / workload keys
         ↓
   data encryption keys (DEK) wrapped by KEK in KMS/HSM

Document purpose binding: a key used for TLS must not be reused for code signing or device attestation.

Generation and storage

Generation:

• Use approved libraries or HSM/KMS GenerateKey APIs
• Enforce minimum sizes (AES-256, RSA ≥2048, EC P-256+)
• Record provenance (who/what created, which HSM slot)

Storage:

Wrapping: DEK encrypted under KEK; rotate KEK without re-encrypting all data when using KMS native rotation, or plan re-wrap jobs.

Rotation and lifecycle

Rotation checklist:

1. Issue new key/cert alongside old (overlap window) 2. Deploy consumers that trust both during migration 3. Revoke or disable old after cutover metrics green 4. Audit logs for stragglers using retired key IDs 5. Update key version metadata in ciphertext headers

Escrow and recovery

Escrow is high risk—require explicit policy:

• When allowed: regulated environments, enterprise recovery with split knowledge
• When forbidden: E2E messaging keys, device-only keys, zero-knowledge designs
• Controls: M-of-N ceremonies, HSM policies, audit every unwrap, time-bound access

Document recovery RTO/RPO without weakening confidentiality for non-escrowed data.

HSM and KMS patterns

IAM: separate roles for encrypt, decrypt, admin, audit; no human uses admin for daily ops.

Cloud notes: enable KMS CloudTrail/audit, deny kms:Disable*, use grants sparingly with expiry.

PKI architecture

Internal CA:

• Offline root; online issuing CA with CRL/OCSP or short-lived certs (prefer latter)
• Name constraints, EKU (serverAuth, clientAuth), max path length
• Certificate Transparency for public TLS where applicable

Profiles:

Revocation: prefer short-lived certs over long CRLs; have break-glass revocation procedure.

TLS configuration

Minimum bar (new deployments):

• TLS 1.2+; prefer 1.3 where clients support
• ECDHE forward secrecy; disable static RSA key transport
• AEAD suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256
• Disable TLS 1.0/1.1, 3DES, RC4, NULL, EXPORT

Certificate validation:

• Full chain to trusted store; hostname verification (SAN)
• Consider pinning only with update strategy (SPKI hashes, backup pins)
• OCSP stapling where supported to improve privacy and reliability

Operational:

• Automate renewal; alert at 30/14/7 days
• Document cipher order vs client quirks (legacy mobile, regional regulators)
• Test with sslscan/testssl or CI TLS probes after changes

Monitoring and incident response

Monitor for:

• Cert expiry and failed renewals
• Sudden cipher downgrade or protocol anomalies
• KMS Decrypt spikes, failed authentication to HSM
• New CA issuances outside change windows

On compromise: rotate affected keys, revoke certs, assess wrapped DEK exposure, notify per incident process—not legal advice.

Primitives and algorithm selection

Table of contents

1. Selection framework 2. Symmetric encryption and AEAD 3. Hashes and MACs 4. Asymmetric encryption and key agreement 5. Digital signatures 6. Password hashing vs KDFs 7. Post-quantum awareness 8. Deprecated and avoid

Selection framework

For each security goal, pick the simplest standard construction that meets requirements:

Document key size, expected lifetime, interoperability, and FIPS/compliance constraints.

Symmetric encryption and AEAD

Rules:

• One 256-bit key for AES-GCM in new systems unless legacy forces 128-bit
• Define nonce source (random 96-bit vs deterministic counter with partition)
• Specify associated data (AAD) for metadata that must be authenticated but not encrypted
• Avoid CBC mode for new designs; if legacy CBC exists, require encrypt-then-MAC with careful padding analysis

Hashes and MACs

Do not use fast hashes (MD5, SHA-1) for password storage or signatures.

Asymmetric encryption and key agreement

Hybrid encryption pattern: ephemeral ECDH → HKDF → AEAD for payload. Do not invent custom KDF chains.

Digital signatures

Verify hash algorithm alignment (e.g., ECDSA with SHA-256), curve points validation, and signature malleability where relevant (Bitcoin contexts differ from TLS).

Password hashing vs KDFs

Never: use bare SHA-256 on passwords; reuse password hash as encryption key without domain separation.

Post-quantum awareness

At architecture level (not certification):

• Inventory long-lived confidentiality (archived ciphertext, recorded TLS if HNDL relevant)
• Prefer hybrid key establishment (classical + PQ KEM) where standards and libraries support
• Track NIST PQC selected algorithms and TLS/experimental profiles for your stack
• Plan agility: algorithm identifiers, version negotiation, cipher suite extensibility

Do not deploy experimental PQ without library maturity review and rollback plan.

Deprecated and avoid

Maintain an internal approved-algorithms list with sunset dates and exception process.

Protocol design and security properties

Table of contents

1. Security properties glossary 2. Protocol review method 3. Handshakes and key derivation 4. Downgrade and replay 5. Transcript binding and channel binding 6. Session management 7. Common protocol patterns 8. Formal verification fit

Security properties glossary

Clarify which property applies to which layer (transport vs application message).

Protocol review method

1. Diagram participants, messages, and trust boundaries 2. List cryptographic inputs per message (keys, nonces, AD, identities) 3. For each message, state what breaks if an attacker modifies, drops, or replays it 4. Trace key derivation tree from long-term secrets to session keys 5. Check composition with TLS (what is protected below vs at app layer) 6. Record assumptions (clock sync, trusted CA, secure enrollment) 7. Compare to known attacks (MITM, version rollback, key compromise impersonation)

Deliver a residual risk table with severity and mitigations.

Handshakes and key derivation

Good practice:

• Use authenticated key exchange (signed server params, certs, or mutual auth)
• Derive keys with HKDF or protocol-standard KDF (TLS 1.3 key schedule)
• Bind keys to context: protocol version, ciphersuite, client/server identities
• Separate keys by direction and purpose (encrypt vs MAC vs IV generation)

Anti-patterns:

• Shared static symmetric key for all clients
• Encrypting under long-term RSA without freshness
• Custom hash chains without analysis
• Ignoring identity in KDF input (wrong peer key)

Downgrade and replay

Downgrade resistance:

• Include version and ciphersuite in signed or MAC'd transcript (TLS 1.3 does via Finished)
• Reject unknown versions explicitly; no silent fallback to weak crypto
• Log and alert on fallback events in clients

Replay:

• Use session identifiers + monotonic counters or sliding windows
• For stateless APIs, signed timestamps with short skew + nonce store
• Distinguish at-least-once delivery (idempotent handlers) from crypto replay

Transcript binding and channel binding

Transcript binding: signatures or MACs cover the full negotiation so MITM cannot splice parameters.

Channel binding (tls-unique, tls-exporter):

• Tie application auth to the underlying TLS channel
• Prevents credential forwarding to different TLS sessions
• Specify which exporter label and length per RFC 5705 / 8446

Document if application crypto is independent of TLS (double encryption) and why.

Session management

TLS 1.3 0-RTT: replay of early data possible—never use for non-idempotent operations without anti-replay at app layer.

Common protocol patterns

Formal verification fit

When stakeholders need machine-checked arguments:

Properties to state: confidentiality(sk, attacker), event(accept) ==> event(run), executable

Scope limits: models abstract crypto; implementation bugs (timing, memory) need separate review.

Pair with crypto-protocol-diagram and mermaid-to-proverif (agent catalog) for diagram-to-model workflows.