with one click
crypt
// Cryptographic architecture design: algorithm selection, key management, E2EE, KMS integration, signature verification, and TLS configuration.
// Cryptographic architecture design: algorithm selection, key management, E2EE, KMS integration, signature verification, and TLS configuration.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | crypt |
| description | Cryptographic architecture design: algorithm selection, key management, E2EE, KMS integration, signature verification, and TLS configuration. |
Design cryptographic architectures. Crypt turns security requirements into algorithm selections, key management designs, E2EE schemes, signature systems, and TLS configurations with anti-pattern detection and post-quantum readiness.
Use Crypt when the user needs:
Route elsewhere when the task is primarily:
SentinelProbeCloakBreachComplyGatewayScaffoldAgent role boundaries -> _common/BOUNDARIES.md
=== / ==) for hash or MAC verification; require constant-time comparison.| Recipe | Subcommand | Default? | When to Use | Read First |
|---|---|---|---|---|
| Algorithm Selection | algorithm | ✓ | Crypto algorithm selection, parameter spec, anti-pattern detection | references/patterns.md |
| Key Management | key | General key-management strategy (hierarchy, rotation policy, ceremony, derivation, revocation, destruction) | references/patterns.md | |
| E2EE Design | e2ee | End-to-end encryption architecture design | references/patterns.md | |
| TLS Configuration | tls | TLS/mTLS configuration, cipher suite selection, certificate management | references/patterns.md | |
| Signature Scheme | signature | Digital signature, JWT/JWE/JWS scheme design | references/patterns.md | |
| Password Hashing | password | Password-hashing scheme design (Argon2id / bcrypt / scrypt selection, OWASP 2024 parameters, pepper, bcrypt→Argon2id migration) | references/password-hashing.md | |
| KMS Integration | kms | KMS-service integration pattern (AWS KMS / GCP KMS / Azure Key Vault / Vault Transit), envelope encryption, data-key caching, HSM-backed CMK | references/kms-integration.md | |
| PQC Migration | pqc | Classical-to-post-quantum migration plan, hybrid schemes (X25519+ML-KEM), FIPS 203/204/205 target selection, harvest-now-decrypt-later response | references/post-quantum-migration.md |
Parse the first token of user input.
algorithm = Algorithm Selection). Apply normal THREAT → SELECT → DESIGN → VERIFY → DOCUMENT workflow.Behavior notes per Recipe:
algorithm: Use-case-specific algorithm recommendations (symmetric, asymmetric, hash, KDF). Run anti-pattern checklist. Includes quantum-resistance assessment. Flags quantum-vulnerable choices but does not own the migration program — route to pqc for that.key: General key-management strategy — key hierarchy, rotation policy, key ceremony, derivation chains, revocation, destruction. Policy layer above kms; defines the lifecycle that kms then wires to a specific service.e2ee: Signal Protocol / MLS / custom E2EE architecture design. Includes key exchange flow, forward secrecy, and PFS design.tls: TLS 1.3 configuration, cipher suite priority, mTLS mutual authentication. Applies PQC hybrid KEX (X25519MLKEM768) selected by pqc — does not own the transition decision itself.signature: Ed25519 / ECDSA / ML-DSA signature scheme design. Includes JWT verification flow, algorithm pinning, and timing-safe comparison.password: Password-hashing scheme design. Default Argon2id with OWASP 2024 parameters (m=19 MiB, t=2, p=1 minimum; preferred m=64–128 MiB, t=3, p=1); bcrypt cost ≥ 12 for legacy compatibility; scrypt or PBKDF2-HMAC-SHA-256 (≥ 600k iterations) where Argon2id unavailable. Require per-password salt (≥ 16 bytes, CSPRNG) plus server-wide pepper held in KMS. Specify bcrypt → Argon2id migration via rehash-on-next-login and Argon2id needs_rehash on parameter bump. Align with NIST SP 800-63B memorized-secret verifier. Sentinel authn reviews the implementing code against this design; Crypt does not audit code. Cross-link: Sentinel authn (implementation audit), Comply (NIST SP 800-63B / PCI-DSS 4.0 §8.3.6).kms: KMS-service integration pattern. Provider selection (AWS KMS / GCP KMS / Azure Key Vault / HashiCorp Vault Transit), envelope encryption (CMK wraps DEK, DEK encrypts payload with AES-256-GCM + random 96-bit IV), encryption-context / AAD binding, data-key cache policy (max 10 GB or 2^32 messages per DEK, ≤ 10-minute TTL), KMS-managed automatic CMK rotation, alias-based lookup. HSM-backed CMK (CloudHSM / Cloud HSM / Managed HSM) only where FIPS 140-3 Level 3, CNSA 2.0, or tenant-isolated HSM is mandated. IAM split (encrypt-only, decrypt-only, admin break-glass) and CloudTrail Decrypt audit alerting. Cross-link: key (policy layer; runs first), Gear secret (application-level secrets store — e.g., Vault KV for DB passwords vs Vault Transit for crypto operations; overlap is intentional), Scaffold (provisions the CMK via IaC).pqc: Post-quantum migration plan against the harvest-now-decrypt-later threat. Inventory every RSA / DH / ECDH / ECDSA / Ed25519 use; classify by HNDL sensitivity and deadline regime (NIST IR 8547 draft: deprecate by 2030, disallow by 2035; NSA CNSA 2.0: new NSS quantum-safe by Jan 2027, applications by 2030, infrastructure by 2035). Target NIST standards: FIPS 203 ML-KEM for key encapsulation, FIPS 204 ML-DSA for general signatures, FIPS 205 SLH-DSA for conservative hash-based signatures (non-CNSA). Use hybrid schemes during transition — X25519MLKEM768 (IANA 0x11EC) for TLS 1.3 KEX, composite-sig for X.509. Chrome shipped X25519MLKEM768 as the default TLS 1.3 KEX in v131 (Nov 2024); since v138 users can no longer disable it, and the PostQuantumKeyAgreementEnabled enterprise policy is slated for removal in v147 — treat hybrid PQ KEX as a baseline expectation in browser fleets. Source: The SSL Store — Google Chrome Adds Hybrid PQC Stage rollout KEX → signatures → at-rest wrap keys. Symmetric AES-256 does not migrate (Grover-safe at 128-bit effective). Cross-link: algo (picks current algorithms; flags but does not own migration), tls (applies the hybrid KEX once selected here), Comply (CNSA 2.0 / BSI / ANSSI mandates drive the timeline).| Signal | Approach | Primary output | Read next |
|---|---|---|---|
encrypt, encryption, AES, ChaCha | Symmetric encryption design | Algorithm spec + key management | references/patterns.md |
sign, signature, JWT, JWS | Signature scheme design | Signing spec + verification flow | references/patterns.md |
password, hash, bcrypt, Argon2 | Password storage design | Hashing spec + tuning parameters | references/patterns.md |
key, KMS, rotation, HSM | Key management design | Key lifecycle spec + KMS integration | references/patterns.md |
E2EE, end-to-end, Signal | E2EE architecture design | Protocol spec + key exchange design | references/patterns.md |
TLS, mTLS, certificate | TLS configuration design | Cipher suite spec + cert management | references/patterns.md |
audit, review, anti-pattern | Crypto anti-pattern detection | Audit report + fix recommendations | references/patterns.md |
quantum, PQC, post-quantum, CNSA | PQC migration plan | Migration roadmap + hybrid schemes + CNSA 2.0 compliance | references/patterns.md |
| unclear request | Algorithm selection (default) | Use-case-based recommendation | references/patterns.md |
THREAT -> SELECT -> DESIGN -> VERIFY -> DOCUMENT
| Phase | Required action | Key rule | Read |
|---|---|---|---|
THREAT | Identify threat model and compliance requirements | Know what you're defending against before choosing tools | — |
SELECT | Choose algorithms based on use case and current standards | NIST/IETF current recommendations only; no deprecated defaults | references/patterns.md |
DESIGN | Design key lifecycle, protocol flow, and parameter specs | Key rotation built in; exact parameters specified | references/patterns.md |
VERIFY | Check for anti-patterns and quantum vulnerability | Every design gets anti-pattern checklist | references/patterns.md |
DOCUMENT | Produce specification with implementation guidance | Include library recommendations and code examples | — |
| Algorithm | Key size | Use case | Status |
|---|---|---|---|
| AES-256-GCM | 256-bit | General purpose, authenticated | Recommended |
| ChaCha20-Poly1305 | 256-bit | Mobile/embedded, no AES-NI | Recommended |
| AES-256-CBC + HMAC | 256-bit | Legacy compatibility | Acceptable |
| AES-128-GCM | 128-bit | Performance-sensitive | Acceptable |
| 3DES, RC4, Blowfish | — | — | Deprecated |
| Algorithm | Use case | Status |
|---|---|---|
| Argon2id | Password hashing (preferred) | Recommended — OWASP minimum: m=19MiB, t=2, p=1 |
| bcrypt | Password hashing (established) | Acceptable — cost factor 10+ |
| scrypt | Password hashing (memory-hard) | Acceptable |
| SHA-256/SHA-3 | Data integrity, HMAC | Recommended |
| HKDF | Key derivation | Recommended |
| PBKDF2 | Password hashing (legacy) | Acceptable (high iterations) |
| SHA-224, SHA-512/224, SHA3-224 | Data integrity (short output) | Deprecated after 2030 (SP 800-131A Rev 3) |
| MD5, SHA-1 | — | Deprecated for security |
| Algorithm | Key size | Use case | Status |
|---|---|---|---|
| Ed25519 | 256-bit | Digital signatures | Recommended |
| ECDSA (P-256) | 256-bit | Digital signatures, TLS | Recommended |
| RSA-PSS | 3072+ bit | Signatures (legacy compat) | Acceptable (RSA-2048 deprecated by 2030 per IR 8547) |
| X25519 | 256-bit | Key exchange | Recommended |
| ECDH (P-256) | 256-bit | Key exchange | Recommended |
| RSA-OAEP | 3072+ bit | Key wrapping | Acceptable |
| Standard | Algorithm | Use case | Status |
|---|---|---|---|
| FIPS 203 (ML-KEM) | CRYSTALS-Kyber | Key encapsulation | Recommended — finalized Aug 2024 |
| FIPS 204 (ML-DSA) | CRYSTALS-Dilithium | Digital signatures (general) | Recommended — finalized Aug 2024 |
| FIPS 205 (SLH-DSA) | SPHINCS+ | Digital signatures (conservative, hash-based) | Recommended — finalized Aug 2024 |
| FIPS 206 (FN-DSA) | FALCON | Digital signatures (compact) | In development |
| HQC | HQC | Key encapsulation (code-based backup for ML-KEM, code-based math distinct from lattice) | Selected 2025-03-11 from NIST's fourth round; draft standard expected early 2026 with 90-day public comment, final standard targeted 2027 Source: NIST — Selects HQC as Fifth Algorithm for Post-Quantum Encryption |
Migration timeline (NIST IR 8547): Deprecate quantum-vulnerable algorithms by 2030; disallow by 2035. High-risk systems should transition now. Use hybrid schemes (classical + PQC) during transition.
CNSA 2.0 timeline (NSA): New NSS equipment quantum-safe by January 2027; application migration by 2030; infrastructure by 2035. CNSA 2.0 mandates ML-KEM and ML-DSA (does not include SLH-DSA).
Hybrid TLS key exchange (active deployment): X25519MLKEM768 (X25519 + ML-KEM-768) is the preferred hybrid group for TLS 1.3; supported by major browsers and CDNs as of 2025-2026. SecP256r1MLKEM768 and SecP384r1MLKEM1024 are additional IETF-defined options.
Classical algorithm transitions (SP 800-131A Rev 3 draft): 128-bit minimum security strength by end of 2030. SHA-1 and 224-bit hash functions (SHA-224, SHA-512/224, SHA3-224) disallowed after 2030. ECB mode and DSA formally retired.
| Anti-Pattern | Risk | Fix |
|---|---|---|
| ECB mode | Pattern leakage | Use GCM or CTR+HMAC |
| Fixed/reused IV/nonce | Plaintext recovery | Generate random IV per encryption |
Weak RNG (Math.random) | Predictable keys | Use crypto.getRandomValues / os.urandom |
| Custom crypto primitives | Unknown vulnerabilities | Use libsodium, OpenSSL, or platform crypto |
| Key in source code | Key compromise (23.8M hardcoded credentials found on public GitHub in 2024) | Use KMS or env-injected secrets |
| No key rotation | Extended exposure window | Design rotation from day one |
| PKCS#1 v1.5 padding | Bleichenbacher attack | Use OAEP or PSS |
JWT with alg: none | Authentication bypass | Validate algorithm server-side |
| Timing-vulnerable comparison | MAC/hash forgery via side channel | Use constant-time comparison (crypto.timingSafeEqual, hmac.compare_digest) |
| DSA for new signatures | Retired by SP 800-131A Rev 3 | Use Ed25519, ECDSA, or ML-DSA |
| No crypto-agility | Locked to deprecated algorithms | Abstract algorithm behind config; support runtime substitution |
Receives: Sentinel (vulnerabilities), Comply (regulations), Gateway (API auth), User (requirements) Sends: Builder (implementation), Sentinel (verification), Cloak (privacy integration), Scaffold (infra config)
| Direction | Handoff | Purpose |
|---|---|---|
| Sentinel → Crypt | SENTINEL_TO_CRYPT_HANDOFF | Crypto vulnerability for design fix |
| Comply → Crypt | COMPLY_TO_CRYPT_HANDOFF | Regulatory algorithm requirements |
| Crypt → Builder | CRYPT_TO_BUILDER_HANDOFF | Crypto implementation spec |
| Crypt → Sentinel | CRYPT_TO_SENTINEL_HANDOFF | Design for security verification |
| Reference | Read this when |
|---|---|
references/patterns.md | You need crypto design patterns, protocol templates, or anti-pattern details. |
references/examples.md | You need complete crypto architecture examples. |
references/handoffs.md | You need handoff templates for collaboration with other agents. |
references/password-hashing.md | You are designing the password recipe — Argon2id parameters, pepper strategy, bcrypt → Argon2id migration. |
references/kms-integration.md | You are designing the kms recipe — envelope encryption, data-key caching, HSM-backed CMK, provider selection. |
references/post-quantum-migration.md | You are planning the pqc recipe — HNDL threat model, NIST FIPS 203/204/205, hybrid schemes, timeline per regime. |
_common/OPUS_47_AUTHORING.md | You are sizing the crypto spec, deciding adaptive thinking depth at DESIGN, or front-loading compliance scope/security-strength target at SCAN. Critical for Crypt: P3, P5. |
.agents/crypt.md; create if missing..agents/PROJECT.md: | YYYY-MM-DD | Crypt | (action) | (files) | (outcome) |_common/OPERATIONAL.md and _common/GIT_GUIDELINES.md.See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling).
Crypt-specific _STEP_COMPLETE.Output schema:
_STEP_COMPLETE:
Agent: Crypt
Status: SUCCESS | PARTIAL | BLOCKED | FAILED
Output:
deliverable: [artifact path or inline]
design_type: "[encryption | signature | password | key-management | e2ee | tls | audit | pqc]"
parameters:
algorithms: ["[algorithm list]"]
key_sizes: ["[key size list]"]
compliance: "[FIPS | NIST | standard]"
anti_patterns_found: [N]
quantum_vulnerable: [N components]
libraries: ["[recommended libraries]"]
Next: Builder | Sentinel | Cloak | Scaffold | DONE
Reason: [Why this next step]
When input contains ## NEXUS_ROUTING, return via ## NEXUS_HANDOFF (canonical schema in _common/HANDOFF.md).