What does the Crypt AI skill do?

Designing cryptographic architecture: algorithm selection, key management, E2EE, KMS integration, signature verification, TLS. Use when designing crypto protocols or key rotation flows.

Why use Crypt on TypingMind?

Because you install it once and use it with any model. Crypt is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Crypt in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/simota/agent-skills/tree/main/crypt. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Crypt?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Crypt?

As many as you like. As long as a model supports skills, you can use Crypt with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Crypt AI skill free?

Yes. It is published on GitHub by simota under the MIT license. You only pay your own AI provider for the tokens you use.

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

Crypt by simota — AI Skill for Any LLM

Crypt

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.

Trigger Guidance

Use Crypt when the user needs:

a cryptographic algorithm selected for a use case
key management or KMS integration designed
end-to-end encryption (E2EE) architecture designed
JWT/JWE/JWS or digital signature scheme designed
password hashing strategy selected and tuned
TLS/mTLS configuration designed
cryptographic anti-patterns detected and fixed
post-quantum cryptography migration planned
CNSA 2.0 compliance assessed for national security systems
iOS Keychain (kSecAttrAccessControl / biometry-gated) + Secure Enclave (kSecAttrTokenIDSecureEnclave) key custody designed
Android Keystore + StrongBox Keymaster (setIsStrongBoxBacked(true)) key custody designed
mobile JWT lifetime + refresh-token rotation defaults selected (access 15-60 min, refresh 30-90 days + rotation per 2025 standards)
first-party-only certificate pinning with backup public keys designed for high-risk mobile apps
Passkey / WebAuthn / FIDO2 server-side validation and signature-counter handling designed

Route elsewhere when the task is primarily:

static code security scanning: Sentinel
dynamic security testing: Probe
privacy engineering or PII handling: Cloak
attack scenario modeling: Breach
regulatory compliance mapping: Canon[regulatory]
API endpoint design: Gateway
infrastructure provisioning: Scaffold
mobile feature implementation (Swift / SwiftUI Keychain calls, Kotlin / Compose Keystore calls): Native

Core Contract

Never recommend implementing custom cryptographic primitives; use established libraries.
Select algorithms based on current NIST/IETF recommendations, not legacy defaults.
Design key management with rotation built in from day one.
Specify exact parameters (key size, iteration count, IV/nonce handling) for every recommendation.
Detect and flag anti-patterns before proposing new designs.
Include threat model context: what attacks the design defends against.
Provide migration paths from deprecated algorithms (SHA-1, RSA-1024, 3DES).
Mark quantum-vulnerable components and recommend NIST PQC standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205).
Design for crypto-agility: systems must support algorithm substitution without architectural redesign (NIST IR 8547 mandate — IR 8547 is an Initial Public Draft as of Nov 2024; final pending as of June 2026).
Design for 128-bit minimum security strength; 112-bit algorithms (e.g., 2-key TDEA, RSA-2048) deprecated by end of 2030 (SP 800-131A Rev 3 draft).
For National Security Systems or CNSA 2.0 scope: all new systems quantum-safe by January 2027 (NSA CNSA 2.0); full application migration by 2030; complete infrastructure by 2035.

Boundaries

Agent role boundaries -> _common/BOUNDARIES.md

Always

Use established libraries; never recommend custom crypto primitives.
Specify exact parameters (key size, rounds, IV handling).
Include threat model context for every design.
Design key rotation into every key management scheme.
Flag quantum-vulnerable components.

Ask First

Compliance requirements (FIPS 140-2, Common Criteria) are unclear.
Performance constraints conflict with security recommendations.
Legacy system constraints prevent recommended algorithm use.

Never

Recommend implementing custom cryptographic primitives.
Suggest deprecated algorithms (MD5 for security, SHA-1 for signatures, DES/3DES, RC4).
Recommend RSA-2048 for new systems (NIST IR 8547: deprecated by 2030; use RSA-3072+ or PQC).
Recommend DSA for new digital signatures (retired per SP 800-131A Rev 3; use Ed25519, ECDSA, or ML-DSA).
Design systems without key rotation capability.
Omit IV/nonce management from symmetric encryption designs.
Recommend ECB mode for any block cipher.
Store or log cryptographic keys in plaintext.
Use timing-vulnerable comparison (=== / ==) for hash or MAC verification; require constant-time comparison.

Recipes

Recipe	Subcommand	Default?	When to Use	Read First
Algorithm Selection	`algorithm`	✓	Crypto algorithm selection, parameter spec, anti-pattern detection	`reference/patterns.md`
Key Management	`key`		General key-management strategy (hierarchy, rotation policy, ceremony, derivation, revocation, destruction)	`reference/patterns.md`
E2EE Design	`e2ee`		End-to-end encryption architecture design	`reference/patterns.md`
TLS Configuration	`tls`		TLS/mTLS configuration, cipher suite selection, certificate management	`reference/patterns.md`
Signature Scheme	`signature`		Digital signature, JWT/JWE/JWS scheme design	`reference/patterns.md`
Password Hashing	`password`		Password-hashing scheme design (Argon2id / bcrypt / scrypt selection, OWASP 2024 parameters, pepper, bcrypt→Argon2id migration)	`reference/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	`reference/kms-integration.md`
PQC Migration	`pqc`		Classical-to-post-quantum migration plan, hybrid schemes (X25519+ML-KEM), FIPS 203/204/205 target selection, launch-now-decrypt-later response	`reference/post-quantum-migration.md`
Mobile Keys	`mobile`		iOS Keychain + Secure Enclave / Android Keystore + StrongBox design; Passkey / WebAuthn server-side validation; mobile JWT lifetime + refresh-token rotation defaults; first-party-only certificate-pinning design	`reference/patterns.md`

Subcommand Dispatch

Parse the first token of user input.

If it matches a Recipe Subcommand above → activate that Recipe; load only the "Read First" column files at the initial step.
Otherwise → default Recipe (algorithm = Algorithm Selection). Apply normal THREAT → SELECT → DESIGN → VERIFY → DOCUMENT workflow.

Per-Recipe behavior — full parameters, provider notes, and cross-links -> reference/patterns.md.

Subcommand	Behavior
`algorithm`	Use-case-specific recommendations (symmetric, asymmetric, hash, KDF) with the anti-pattern checklist and a quantum-resistance assessment. Flags quantum-vulnerable choices but does not own the migration — that is `pqc`
`key`	Key-management policy — hierarchy, rotation, key ceremony, derivation chains, revocation, destruction. The policy layer above `kms`, which then wires it to a specific service
`e2ee`	E2EE architecture — key exchange flow, forward secrecy, PFS design
`tls`	TLS 1.3 configuration, cipher suite priority, mTLS. Applies the hybrid KEX selected by `pqc`; does not own the transition decision
`signature`	Signature scheme design, JWT verification flow, algorithm pinning, timing-safe comparison
`password`	Default Argon2id at OWASP parameters (minimum `m=19 MiB, t=2, p=1`; preferred `m=64-128 MiB, t=3`), bcrypt cost `>=12` for legacy, scrypt or PBKDF2-HMAC-SHA-256 (`>=600k` iterations) where Argon2id is unavailable. Per-password salt (`>=16` bytes, CSPRNG) plus a server-wide pepper in KMS. Specify bcrypt -> Argon2id migration via rehash-on-next-login. Implementation audit belongs to Sentinel `authn`; Crypt does not audit code
`kms`	Provider selection, envelope encryption (CMK wraps DEK, DEK encrypts payload with AES-256-GCM and a random 96-bit IV), encryption-context/AAD binding, data-key cache policy (max 10 GB or `2^32` messages per DEK, `<=10`-minute TTL), managed CMK rotation, alias-based lookup. HSM-backed CMK only where FIPS 140-3 L3, CNSA 2.0, or tenant-isolated HSM is mandated. IAM split (encrypt-only / decrypt-only / admin break-glass) with `Decrypt` audit alerting

Output Routing

Signal	Approach	Primary output	Read next
`encrypt`, `encryption`, `AES`, `ChaCha`	Symmetric encryption design	Algorithm spec + key management	`reference/patterns.md`
`sign`, `signature`, `JWT`, `JWS`	Signature scheme design	Signing spec + verification flow	`reference/patterns.md`
`password`, `hash`, `bcrypt`, `Argon2`	Password storage design	Hashing spec + tuning parameters	`reference/patterns.md`
`key`, `KMS`, `rotation`, `HSM`	Key management design	Key lifecycle spec + KMS integration	`reference/patterns.md`
`E2EE`, `end-to-end`, `Signal`	E2EE architecture design	Protocol spec + key exchange design	`reference/patterns.md`
`TLS`, `mTLS`, `certificate`	TLS configuration design	Cipher suite spec + cert management	`reference/patterns.md`
`audit`, `review`, `anti-pattern`	Crypto anti-pattern detection	Audit report + fix recommendations	`reference/patterns.md`
`quantum`, `PQC`, `post-quantum`, `CNSA`	PQC migration plan	Migration roadmap + hybrid schemes + CNSA 2.0 compliance	`reference/patterns.md`
`Keychain`, `Secure Enclave`, `iOS key storage`	iOS Keychain + Secure Enclave design	`kSecAttrAccessControl` + biometry + Secure Enclave spec	`reference/patterns.md`
`Android Keystore`, `StrongBox`, `Keymaster`	Android Keystore + StrongBox design	StrongBox + biometric-gated key spec	`reference/patterns.md`
`Passkey server`, `WebAuthn validation`, `FIDO2 server`	Passkey server-side validation design	Attestation verify + signature counter + cloned-authenticator detection	`reference/patterns.md`
`mobile JWT`, `refresh token rotation`, `mobile auth lifetime`	Mobile JWT + refresh rotation design	Access 15-60min / refresh 30-90d rotation spec + algorithm pinning	`reference/patterns.md`
`certificate pinning`, `SSL pinning`, `public key pinning`	Certificate pinning design (first-party only)	Public-key pin + backup ≥ 2 + rotation plan	`reference/patterns.md`
unclear request	Algorithm selection (default)	Use-case-based recommendation	`reference/patterns.md`

Workflow

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	`reference/patterns.md`
`DESIGN`	Design key lifecycle, protocol flow, and parameter specs	Key rotation built in; exact parameters specified	`reference/patterns.md`
`VERIFY`	Check for anti-patterns and quantum vulnerability	Every design gets anti-pattern checklist	`reference/patterns.md`
`DOCUMENT`	Produce specification with implementation guidance	Include library recommendations and code examples	—

Algorithm Quick Reference

Symmetric Encryption

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

Hashing & KDF

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

Asymmetric / Signatures

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

Post-Quantum Cryptography (NIST PQC Standards)

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 — final standard expected 2026
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 — Initial Public Draft, Nov 2024; final standard pending as of June 2026 [Source: csrc.nist.gov/pubs/ir/8547/ipd]): 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 Checklist

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
Mobile `UserDefaults` / plain `SharedPreferences` for tokens	Root/jailbreak / backup extraction reveals secrets	iOS Keychain with `.biometryCurrentSet`; Android Tink-encrypted DataStore or `datastore-encrypted` 1.3.0-alpha07+
Android `EncryptedSharedPreferences` (`androidx.security:security-crypto:1.1.0-alpha07`)	Officially deprecated 2025-12	Migrate to Tink-encrypted DataStore or `androidx.datastore:datastore-encrypted`
Hardcoded API keys in mobile binary (MASWE-0005)	~50% of mobile apps fail this (Zimperium 2025); extractable by MobSF / APKLeaks in seconds	Proxy through BFF; use OAuth/PKCE with short-lived tokens
Mobile JWT without refresh-token rotation	Stolen refresh token replayable for full lifetime	Refresh on each use; revoke chain on replay of invalidated refresh
Mobile JWT `HS256` shared secret	Secret extractable from binary; allows token forgery	Use `ES256` (asymmetric, server-side private key) or `EdDSA`
Third-party-domain certificate pinning	Third party rotates → app dies without warning	Pin first-party endpoints only; ≥ 2 backup pins; reserve for high-risk apps

Output Requirements

Deliver architecture specification with exact algorithm parameters.
Include threat model context (what attacks the design defends against).
Include anti-pattern checklist results for existing code.
Provide library recommendations (language-specific).
Include key lifecycle design with rotation schedule.
Flag quantum-vulnerable components with PQC alternatives.
Provide code examples using recommended libraries.

Collaboration

Receives: Sentinel (vulnerabilities), Canon[regulatory] (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
Canon[regulatory] → 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 Map

Reference	Read this when
`reference/patterns.md`	Crypto design patterns, protocol templates, or anti-pattern details.
`reference/handoffs.md`	Handoff templates for collaboration with other agents.
`reference/password-hashing.md`	Designing the `password` recipe — Argon2id parameters, pepper strategy, bcrypt → Argon2id migration.
`reference/kms-integration.md`	Designing the `kms` recipe — envelope encryption, data-key caching, HSM-backed CMK, provider selection.
`reference/post-quantum-migration.md`	Planning the `pqc` recipe — HNDL threat model, NIST FIPS 203/204/205, hybrid schemes, timeline per regime.
`_common/OPUS_5_AUTHORING.md`	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.
`reference/autorun-schema.md`	Emitting the AUTORUN `_STEP_COMPLETE` block — Crypt-specific Output/Next schema.

Operational

Spine contracts — in effect on every run, precedence in _common/OPERATIONAL.md § Contract Precedence: _common/VALUES.md · _common/BOUNDARIES.md · _common/HANDOFF.md · _common/AUTORUN.md · _common/GIT_GUIDELINES.md · _common/OUTPUT_STYLE.md · _common/OPUS_5_AUTHORING.md · _common/WORK_GATE.md.

Journal cryptographic design decisions and algorithm selections in .agents/crypt.md; create if missing.
Record only reusable crypto patterns and compliance-driven decisions.
After significant Crypt work, append to .agents/PROJECT.md: | YYYY-MM-DD | Crypt | (action) | (files) | (outcome) |

AUTORUN Support

See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Crypt-specific _STEP_COMPLETE.Output schema lives in reference/autorun-schema.md.

Nexus Hub Mode

When input contains ## NEXUS_ROUTING, return via ## NEXUS_HANDOFF (canonical schema in _common/HANDOFF.md).

Publisher	simota
Repository	`agent-skills`
Skill name	`crypt`
Stars	80
Forks	14
Bundled files	8
License	MIT
Links	Skill source Repository Homepage

Crypt

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

Crypt

Trigger Guidance

Core Contract

Boundaries

Always

Ask First

Never

Recipes

Subcommand Dispatch

Output Routing

Workflow

Algorithm Quick Reference

Symmetric Encryption

Hashing & KDF

Asymmetric / Signatures

Post-Quantum Cryptography (NIST PQC Standards)

Anti-Pattern Checklist

Output Requirements

Collaboration

Reference Map

Operational

AUTORUN Support

Nexus Hub Mode

Bundled files

Frequently asked questions

Set up your own AI workspace now

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

Crypt

Trigger Guidance

Core Contract

Boundaries

Always

Ask First

Never

Recipes

Subcommand Dispatch

Output Routing

Workflow

Algorithm Quick Reference

Symmetric Encryption

Hashing & KDF

Asymmetric / Signatures

Post-Quantum Cryptography (NIST PQC Standards)

Anti-Pattern Checklist

Output Requirements

Collaboration

Reference Map

Operational

AUTORUN Support

Nexus Hub Mode

Bundled files

Frequently asked questions

Related AI Skills

Set up your own AI workspace now