@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/cursor/redux-store-setup/skill.yaml

@@ -1,6 +1,7 @@
 name: redux-store-setup
 version: '1.0.0'
 description: Configure the Redux store with configureStore, middleware, and dev tools
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/redux-testing-patterns/skill.yaml

@@ -1,6 +1,7 @@
 name: redux-testing-patterns
 version: '1.0.0'
 description: Test Redux slices, thunks, selectors, and connected components effectively
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/redux-thunk-pattern/skill.yaml

@@ -1,6 +1,7 @@
 name: redux-thunk-pattern
 version: '1.0.0'
 description: Handle async operations with createAsyncThunk for data fetching and side effects
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/redux-typescript-patterns/skill.yaml

@@ -1,6 +1,7 @@
 name: redux-typescript-patterns
 version: '1.0.0'
 description: Type Redux state, actions, thunks, and hooks with full TypeScript inference
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-bulkhead-pattern/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-bulkhead-pattern
 version: '1.0.0'
 description: Isolate failures with bulkheads to limit blast radius of failing components
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-chaos-testing/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-chaos-testing
 version: '1.0.0'
 description: Validate resilience by injecting controlled failures with chaos engineering techniques
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-circuit-breaker/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-circuit-breaker
 version: '1.0.0'
 description: Protect services from cascading failures with the circuit breaker pattern
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-dead-letter/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-dead-letter
 version: '1.0.0'
 description: Handle permanently failing messages with dead letter queues for inspection and reprocessing
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-fallback-pattern/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-fallback-pattern
 version: '1.0.0'
 description: Provide degraded but functional responses when primary operations fail
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-health-checks/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-health-checks
 version: '1.0.0'
 description: Implement health check endpoints for service readiness and liveness monitoring
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-idempotency/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-idempotency
 version: '1.0.0'
 description: Ensure safe retries with idempotency keys and at-least-once delivery guarantees
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-rate-limiting/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-rate-limiting
 version: '1.0.0'
 description: Control request throughput with rate limiting using token bucket and sliding window algorithms
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-retry-pattern/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-retry-pattern
 version: '1.0.0'
 description: Handle transient failures with configurable retry strategies and backoff
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/resilience-timeout-pattern/skill.yaml

@@ -1,6 +1,7 @@
 name: resilience-timeout-pattern
 version: '1.0.0'
 description: Prevent resource exhaustion with request timeouts and AbortController
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/cursor/security-abac-design/SKILL.md

@@ -0,0 +1,154 @@
+# Attribute-Based Access Control
+
+> Evaluate access decisions using attributes of the subject, resource, action, and environment -- eliminating role explosion by expressing authorization as policy rules over contextual data
+
+## When to Use
+
+- Role explosion makes RBAC unmanageable (too many role combinations needed)
+- Authorization decisions depend on resource attributes (classification level, owner, department, region)
+- Access rules vary by context (time of day, device posture, geographic location, risk score)
+- Compliance requires fine-grained, auditable access policies (healthcare, finance, government)
+- Migrating from hardcoded if/else authorization to a policy engine
+- Implementing data-level access control (row-level or field-level security)
+
+## Threat Context
+
+The complexity of authorization logic is itself a vulnerability surface. Hardcoded if/else authorization scattered across a codebase accumulates inconsistencies: one endpoint checks department, another does not; one checks classification level, another checks role name. The 2023 Microsoft Power Platform vulnerability exposed customer data because one API endpoint checked authentication but not the tenant isolation attribute -- a single missed attribute check exposed cross-tenant data.
+
+The 2019 Capital One breach exploited an SSRF vulnerability that was amplified by overly broad IAM permissions -- ABAC-style attribute constraints on the IAM role (restricting by resource tags and source IP) would have contained the blast radius to the specific application's resources rather than the entire S3 estate. ABAC centralizes policy evaluation, making it auditable, testable, and consistent across all enforcement points. However, poorly designed ABAC policies can themselves become opaque -- a policy engine that no one on the team understands produces a false sense of security.
+
+## Instructions
+
+1. **Identify the four attribute categories.** Every ABAC decision evaluates attributes from four categories:
+   - **Subject attributes:** User ID, roles, department, clearance level, employment status, device trust level, authentication strength
+   - **Resource attributes:** Owner, classification, creation date, department, sensitivity label, data residency region
+   - **Action attributes:** Read, write, delete, approve, export, share, escalate
+   - **Environment attributes:** Current time, IP address, device trust posture, request risk score, network zone (internal/external)
+
+   Access decisions are predicates evaluated over combinations of these attributes. The richer the attribute model, the more precise the policy -- but also the more complex to maintain and debug.
+
+2. **Write policies as rules, not code.** Use a dedicated policy language or engine: OPA/Rego, Cedar (AWS), Casbin, or XACML. Policies should read like business rules, not imperative code. Example in pseudo-policy:
+
+   ```
+   ALLOW action:read
+   ON resource
+   WHERE resource.classification <= subject.clearance
+     AND resource.department == subject.department
+     AND environment.time BETWEEN 09:00 AND 18:00
+   ```
+
+   Separating policy from application code means: policy changes do not require code deployments, code reviews of policy changes focus on business intent rather than implementation details, and the entire policy corpus can be audited independently of the application.
+
+3. **Implement the PDP/PEP architecture.** The four components of a well-structured ABAC system:
+   - **Policy Decision Point (PDP):** Evaluates requests against policies, returns allow/deny with reason. This is the policy engine (OPA, Cedar, etc.).
+   - **Policy Enforcement Point (PEP):** Intercepts application requests and calls the PDP before allowing the operation. Typically implemented as middleware, a gateway filter, or a service mesh sidecar.
+   - **Policy Information Point (PIP):** Provides attribute values the PDP needs but that are not in the request (e.g., looking up the user's department from the directory, fetching the resource's classification from a metadata store).
+   - **Policy Administration Point (PAP):** Manages the policy lifecycle: create, version, test, deploy, audit, and rollback policies.
+
+4. **Default deny.** If no policy explicitly allows the action, deny it. This is the fundamental safety property of ABAC. Every access must be explicitly authorized by at least one matching policy rule. When deploying ABAC to an existing system, start in audit mode (log decisions but do not enforce deny) to discover existing access patterns, then transition to enforcement mode once policies cover all legitimate access.
+
+5. **Design for auditability.** Log every policy decision with: the request attributes (subject, resource, action, environment), the policies evaluated, the matching policy (or lack thereof), and the decision (allow/deny with the specific reason). This decision log is critical for compliance (SOC2, HIPAA, GDPR Article 30), debugging authorization errors reported by users, and detecting policy drift over time. Make the log machine-parseable (structured JSON) for automated analysis and alerting.
+
+6. **Test policies like code.** Write unit tests for policies: given these subject/resource/action/environment attributes, the decision should be allow/deny. Test boundary conditions: what happens when an attribute is missing? What happens when multiple policies apply and one allows while another denies? What happens when environment conditions change (time, network)? Use the policy engine's built-in test framework: OPA has `opa test`, Cedar has `cedar validate` and property-based testing support, Casbin has built-in model testing.
+
+## Details
+
+### ABAC vs RBAC Decision Matrix
+
+RBAC is sufficient when access depends primarily on who the user is (their assigned role). ABAC is needed when access depends on what the resource is, when the access happens, where the user is, or how the resource is classified.
+
+The diagnostic signal for role explosion: if you are encoding attributes into role names to achieve required granularity, you need ABAC. Examples of role name encoding that signals ABAC is needed:
+
+- `us-east-classified-editor` (region + classification + permission baked into role)
+- `cardiology-physician-read` (department + role + action baked into role)
+- `external-contractor-limited-weekday` (trust level + employment type + scope + time baked into role)
+
+Each new dimension multiplies the role count. Three regions, four departments, three classification levels, and two permission levels creates 72 roles. Adding a fifth dimension (time-based access) doubles it to 144 roles. ABAC expresses this as a handful of composable policy rules that evaluate attributes dynamically at decision time.
+
+RBAC and ABAC are not mutually exclusive. A common pattern: use RBAC for coarse-grained feature access (which sections of the application a user can reach) and ABAC for fine-grained data access within those features (which specific records the user can view or modify based on classification, department, and context).
+
+### Policy Engine Comparison
+
+| Engine     | Language                   | Deployment Model          | Strengths                                                                   | Weaknesses                                                |
+| ---------- | -------------------------- | ------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------- |
+| OPA / Rego | Rego (Datalog-inspired)    | Sidecar, library, server  | General-purpose, Kubernetes-native, large ecosystem, rich tooling           | Rego learning curve, not purpose-built for authorization  |
+| Cedar      | Cedar (type-safe)          | Library (Rust, Java, Go)  | Designed for authorization, fast evaluation, formally analyzable, type-safe | AWS-originated, smaller ecosystem, newer                  |
+| Casbin     | Model config + policy file | Embedded library          | Easy integration, supports RBAC/ABAC/ReBAC, many language bindings          | No built-in PDP server, library-only deployment           |
+| XACML      | XML                        | Server (WSO2, Axiomatics) | Industry standard, rich attribute model, mature specification               | XML verbosity, steep learning curve, heavy infrastructure |
+
+Recommendation: Cedar for greenfield authorization services (type safety, fast evaluation, formal analysis tools). OPA for infrastructure and Kubernetes policy (admission control, network policy, cloud resource policy). Casbin for quick integration into existing applications where embedding a library is preferred over deploying a separate service.
+
+### Worked Example -- Healthcare Data Access
+
+**Subject:** Dr. Smith (role: physician, department: cardiology, hospital: General Hospital, employment_status: active)
+
+**Resource:** Patient record #1234 (department: cardiology, classification: PHI, treating_physician: dr-smith, created: 2024-01-15)
+
+**Policy in pseudo-Cedar:**
+
+```
+permit(
+  principal in Role::"physician",
+  action == Action::"read",
+  resource is PatientRecord
+) when {
+  principal.employment_status == "active" &&
+  (resource.treating_physician == principal.id ||
+   resource.department == principal.department) &&
+  context.network in ["hospital_internal", "vpn_authenticated"]
+};
+```
+
+This policy allows Dr. Smith to read patient records in cardiology or records where she is the treating physician, but only from the hospital network or VPN. Adding a time constraint (`context.time.hour >= 6 && context.time.hour <= 22`) or a device trust check (`context.device_trust >= "managed"`) modifies the policy without any application code changes.
+
+If Dr. Smith transfers to the neurology department, her `department` attribute changes in the directory, and she automatically loses access to cardiology records she is not treating -- no role reassignment, no permission matrix update, no code change. The policy adapts because it evaluates live attributes, not static role assignments.
+
+### Migrating from RBAC to ABAC
+
+Most systems start with RBAC and evolve toward ABAC as authorization requirements grow more complex. A phased migration approach:
+
+1. **Identify ABAC candidates:** Audit existing authorization checks for patterns that encode attributes into role names, hardcode resource properties in if/else chains, or require frequent role creation for new business scenarios. These are ABAC candidates.
+
+2. **Deploy the policy engine in shadow mode:** Run the ABAC engine alongside existing authorization. Log ABAC decisions without enforcing them. Compare ABAC decisions to existing RBAC decisions to verify policy correctness.
+
+3. **Migrate one resource type at a time:** Start with the resource type that has the most complex authorization rules (usually the one causing the most role proliferation). Write ABAC policies for that resource type, test thoroughly, then switch enforcement.
+
+4. **Keep RBAC for simple cases:** Not everything needs ABAC. Feature-level access ("can this user access the admin panel?") is well-served by RBAC. Data-level access ("can this user read this specific patient record?") benefits from ABAC. Use both models where each excels.
+
+### Performance Considerations
+
+ABAC policy evaluation adds latency to every authorization-gated request. At scale, this latency must be managed:
+
+- **Policy compilation:** Pre-compile policies into optimized decision structures (decision tables, decision trees) at deploy time rather than interpreting policy text at each request. Cedar and OPA both support ahead-of-time compilation.
+
+- **Attribute caching:** Cache frequently accessed subject and resource attributes with short TTLs (30-60 seconds). Stale attributes introduce a consistency window where revoked access may still be granted -- size the TTL to match your risk tolerance and the sensitivity of the data being protected.
+
+- **Partial evaluation:** Pre-compute policy decisions for known attribute combinations and cache the results. When a request arrives matching a cached combination, return the cached decision without full evaluation.
+
+- **Co-locate PDP with PEP:** Deploy the policy engine as a sidecar container or embedded library rather than a remote centralized service. Network round-trips to a remote PDP add 1-5ms per request; a co-located PDP adds microseconds.
+
+- **Batch evaluation:** When rendering a list of resources (e.g., a file listing or record table), batch the authorization checks into a single PDP call rather than making one call per resource. Most policy engines support batch check APIs.
+
+### ABAC and Compliance
+
+ABAC naturally supports compliance requirements because every decision is logged with full attribute context:
+
+- **HIPAA:** Access to PHI must be limited to authorized individuals with a treatment relationship. ABAC policies encode this directly: `resource.type == "PHI" AND (subject.role == "treating_physician" OR subject.has_treatment_relationship(resource.patient_id))`.
+
+- **GDPR Article 25 (Data Protection by Design):** ABAC enables data minimization by restricting access to specific data fields based on purpose. A marketing analyst can see aggregate data but not individual records. A support agent can see the customer name but not the full payment details.
+
+- **SOC2 CC6.1 (Logical Access):** Requires that access is restricted based on the principle of least privilege. ABAC decision logs provide direct evidence of this: every access was evaluated against policies, and the decision (allow/deny) with full context is recorded.
+
+- **PCI-DSS Requirement 7:** Restrict access to cardholder data by business need to know. ABAC policies can encode cardholder data access rules centrally, and the decision log serves as audit evidence.
+
+## Anti-Patterns
+
+1. **ABAC without centralized policy management.** Scattering attribute checks across the codebase (`if user.dept == resource.dept && user.clearance >= resource.level`) is ad-hoc conditional authorization with extra complexity, not ABAC. True ABAC requires a policy engine to centralize evaluation, provide decision logging, enable policy testing independent of application code, and support policy versioning and rollback.
+
+2. **Over-specifying policies.** Policies with 10+ attribute conditions are difficult to understand, test, maintain, and explain to auditors. If a policy requires more than 5 conditions, decompose it into composable sub-policies with descriptive names: `is_treating_physician`, `is_on_trusted_network`, `has_sufficient_clearance`. Composition makes policies readable, testable, and reusable.
+
+3. **Missing attribute validation.** If the PDP accepts attribute values without validating their source and integrity, an attacker who can manipulate attribute values (e.g., setting their own clearance level via an unprotected API, spoofing IP addresses, manipulating request headers) can bypass all policies. Attribute sources must be authoritative (directory service, identity provider, device management platform) and tamper-proof (signed tokens, server-side lookups, not client-supplied values).
+
+4. **No fallback for missing attributes.** If a required attribute is unavailable (PIP is down, user record is incomplete, device posture check times out), the policy must default to deny. Silently skipping an attribute condition because the value is null transforms a transient infrastructure issue into a privilege escalation. Design policies to handle missing attributes explicitly with a deny default.
+
+5. **Policy drift from business intent.** ABAC policies can diverge from actual business requirements when modified incrementally without review. Treat policy changes with the same rigor as production code changes: version control in a repository, peer review by someone who understands the business rules, automated testing against known-good and known-bad access scenarios, and staged rollout (audit mode before enforcement mode).

package/dist/agents/skills/cursor/security-abac-design/skill.yaml

@@ -0,0 +1,41 @@
+name: security-abac-design
+version: '1.0.0'
+description: Attribute-based access control -- policy engines, XACML concepts, attribute evaluation, and when ABAC is the right model over RBAC
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-rbac-design
+  - security-rebac-design
+  - security-capability-based-security
+  - security-zero-trust-principles
+  - owasp-auth-patterns
+  - owasp-idor-prevention
+stack_signals: []
+keywords:
+  - ABAC
+  - attribute-based access control
+  - policy engine
+  - XACML
+  - OPA
+  - Cedar
+  - policy as code
+  - access control policy
+  - authorization engine
+  - contextual authorization
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/security-asymmetric-encryption/SKILL.md

@@ -0,0 +1,201 @@
+# Asymmetric Encryption
+
+> Public-key cryptography for key exchange, digital signatures, and identity verification
+> -- Ed25519 for signatures, X25519 for key exchange, RSA-2048+ only for legacy
+> compatibility
+
+## When to Use
+
+- Designing a system where parties need to communicate securely without a pre-shared
+  secret
+- Implementing digital signatures for code signing, document signing, or API request
+  authentication
+- Choosing key types for TLS certificates, SSH keys, or JWT signing
+- Evaluating RSA vs elliptic curve algorithms for a new system
+- Implementing a key exchange protocol for end-to-end encryption
+- Reviewing certificate chains, trust models, or PKI configurations
+
+## Threat Context
+
+Asymmetric encryption defends against man-in-the-middle attacks during key exchange,
+impersonation (via digital signatures that prove identity), and the key distribution
+problem (how to establish a shared secret when no secure channel yet exists). RSA with
+keys shorter than 2048 bits is factorable with modern computational resources -- RSA-768
+was factored in 2009 by Kleinjung et al., and NIST deprecated 1024-bit RSA in 2013. The
+looming threat of quantum computing (Shor's algorithm) will eventually break both RSA
+and elliptic curve cryptography by solving integer factorization and the discrete
+logarithm problem in polynomial time, driving the transition to post-quantum algorithms
+(ML-KEM/Kyber, ML-DSA/Dilithium). Current ECC and RSA-3072+ remain secure against all
+known classical attacks.
+
+## Instructions
+
+1. **For digital signatures, default to Ed25519.** Ed25519 (Edwards-curve Digital
+   Signature Algorithm over Curve25519) provides 128-bit security with significant
+   practical advantages: fast signing and verification (tens of thousands of operations
+   per second on commodity hardware), short signatures (64 bytes) and public keys (32
+   bytes), and deterministic signature generation. Determinism eliminates the catastrophic
+   class of bugs where a faulty or biased random number generator leaks the private key
+   through signatures -- the PlayStation 3 ECDSA key extraction (2010) exploited exactly
+   this flaw, where Sony reused a static nonce in ECDSA signatures, allowing attackers to
+   algebraically recover the private signing key. Ed25519 is supported by OpenSSH (since
+   6.5), TLS 1.3, JWT (EdDSA algorithm), GPG, and all modern cryptographic libraries.
+
+2. **For key exchange, default to X25519 (ECDHE).** X25519 performs Elliptic Curve
+   Diffie-Hellman key exchange over Curve25519, producing a 32-byte shared secret from
+   two parties' public keys without either party transmitting the secret. X25519 is the
+   key exchange mechanism in TLS 1.3, the Signal Protocol (used by Signal, WhatsApp, and
+   others), WireGuard VPN, and the Noise Protocol Framework. Always use ephemeral keys
+   (ECDHE -- Elliptic Curve Diffie-Hellman Ephemeral) to achieve forward secrecy: each
+   session generates fresh key pairs, computes the shared secret, derives session keys,
+   and discards the ephemeral private keys. If a long-term key is later compromised, past
+   sessions remain protected because the ephemeral keys no longer exist.
+
+3. **Use RSA only for legacy compatibility.** RSA-2048 is the minimum acceptable key
+   size; RSA-3072 is recommended for new deployments that must use RSA (e.g., for
+   compatibility with systems that do not support ECC). RSA keys are significantly larger
+   than EC keys for equivalent security: 3072-bit RSA provides approximately 128-bit
+   security, matching Curve25519 with a key 96x larger. RSA signing and decryption are
+   computationally expensive (modular exponentiation with large exponents), making RSA
+   substantially slower than Ed25519 for signature operations. For RSA encryption, use
+   OAEP padding (PKCS#1 v2.x) exclusively -- never use PKCS#1 v1.5 padding, which is
+   vulnerable to Bleichenbacher's adaptive chosen-ciphertext attack (1998), a practical
+   attack that recovers plaintext through repeated oracle queries. For RSA signatures,
+   prefer PSS padding (PKCS#1 v2.1) over PKCS#1 v1.5 signatures.
+
+4. **Never encrypt large data with asymmetric encryption directly.** Asymmetric
+   encryption is orders of magnitude slower than symmetric encryption and has inherent
+   message size limits (RSA-2048 with OAEP can encrypt at most ~245 bytes). Use hybrid
+   encryption: generate a random symmetric key (e.g., AES-256), encrypt the bulk data
+   with the symmetric key using an AEAD mode (AES-256-GCM), then encrypt the symmetric
+   key with the recipient's public key. The recipient decrypts the symmetric key with
+   their private key, then decrypts the data. TLS, PGP, and CMS/S/MIME all use this
+   exact pattern.
+
+5. **Protect private keys absolutely.** Private keys must never appear in logs, be
+   transmitted over unencrypted channels, or be stored in plaintext on disk. For highest
+   security, store private keys in Hardware Security Modules (HSMs) or Trusted Platform
+   Modules (TPMs) where the key material never leaves the secure hardware -- signing
+   operations are performed inside the HSM. For software-managed keys, encrypt them at
+   rest with a passphrase or a key encryption key (KEK). Rotate keys on any suspicion of
+   compromise. Use separate key pairs for different purposes: one pair for signing and a
+   different pair for key exchange or encryption, because compromise of one does not then
+   compromise the other.
+
+6. **Understand the security level mapping.** Security level describes the computational
+   effort required to break the algorithm, expressed in bits of equivalent symmetric key
+   strength:
+
+   | Algorithm                    | Key Size | Security Level |
+   | ---------------------------- | -------- | -------------- |
+   | RSA                          | 2048-bit | ~112-bit       |
+   | RSA                          | 3072-bit | ~128-bit       |
+   | RSA                          | 4096-bit | ~140-bit       |
+   | P-256 (secp256r1/prime256v1) | 256-bit  | ~128-bit       |
+   | P-384 (secp384r1)            | 384-bit  | ~192-bit       |
+   | Curve25519 (Ed25519/X25519)  | 256-bit  | ~128-bit       |
+
+   For new systems targeting 128-bit security, Curve25519 is optimal: smallest keys,
+   fastest operations, simplest implementation (constant-time by design, resistant to
+   timing side-channels), and no NSA-related provenance concerns that some practitioners
+   associate with the NIST P-curves.
+
+## Details
+
+### RSA Internals (Conceptual)
+
+RSA security relies on the computational difficulty of factoring the product of two large
+primes. Key generation: choose two large random primes p and q (each ~1536 bits for
+RSA-3072), compute n = p \* q (the modulus), choose public exponent e (conventionally
+65537 = 2^16 + 1, which balances security and verification speed), compute private
+exponent d as the modular inverse of e mod lcm(p-1, q-1). The public key is (n, e); the
+private key is (n, d). Encryption: ciphertext c = m^e mod n. Decryption: plaintext
+m = c^d mod n. Security depends on the assumption that factoring n into p and q is
+computationally infeasible for sufficiently large n. The best known classical factoring
+algorithm (General Number Field Sieve) has sub-exponential but super-polynomial
+complexity, making RSA-3072 secure for the foreseeable classical computing era.
+
+### Elliptic Curve Internals (Conceptual)
+
+ECC security relies on the difficulty of the Elliptic Curve Discrete Logarithm Problem
+(ECDLP). An elliptic curve over a finite field defines a group structure where point
+addition and scalar multiplication are efficient, but the inverse operation (given points
+P and Q = kP, finding the scalar k) is computationally infeasible. Key generation: choose
+a random scalar k (private key) from the curve's order, compute Q = kP (public key)
+where P is the curve's generator point. ECDSA and EdDSA signatures work by encoding a
+proof that the signer knows k without revealing it. ECDH key exchange works by having
+Alice compute k*A * Q*B = k_A * k*B * P and Bob compute k*B * Q*A = k_B * k*A * P,
+arriving at the same shared point. The best known classical attack against ECDLP on
+well-chosen curves is Pollard's rho algorithm with O(sqrt(n)) complexity, making 256-bit
+curves provide 128-bit security.
+
+### Forward Secrecy with Ephemeral Keys
+
+In TLS 1.3, the handshake mandates ephemeral key exchange. Both client and server
+generate fresh X25519 (or P-256) key pairs for each session. The shared secret is
+computed via ECDH, used to derive session keys through HKDF, and the ephemeral private
+keys are immediately discarded. If the server's long-term private key is later
+compromised (through theft, legal compulsion, or cryptanalysis), past session keys cannot
+be recovered because the ephemeral private keys no longer exist. This is forward secrecy,
+also called perfect forward secrecy (PFS). TLS 1.3 removed all non-forward-secret cipher
+suites (static RSA key exchange), making forward secrecy mandatory. Any protocol design
+should follow this example.
+
+### Post-Quantum Considerations
+
+Shor's algorithm on a sufficiently large, fault-tolerant quantum computer solves integer
+factorization and ECDLP in polynomial time, breaking RSA and all standard elliptic curve
+schemes regardless of key size. NIST finalized post-quantum standards in 2024: ML-KEM
+(Module-Lattice Key Encapsulation Mechanism, derived from Kyber) for key exchange, and
+ML-DSA (Module-Lattice Digital Signature Algorithm, derived from Dilithium) for digital
+signatures. Hybrid approaches that combine X25519 + ML-KEM-768 are being deployed in
+production (Chrome, Cloudflare) to provide quantum resistance while maintaining classical
+security as a fallback. Post-quantum signatures (ML-DSA) are significantly larger than
+Ed25519 signatures (2420 bytes vs 64 bytes), which has implications for
+bandwidth-constrained protocols. Begin planning migration paths now: inventory all
+asymmetric cryptographic usage, identify systems most vulnerable to "harvest now, decrypt
+later" attacks (where adversaries record encrypted traffic today for future quantum
+decryption), and prioritize those for hybrid or post-quantum migration.
+
+## Anti-Patterns
+
+1. **RSA-1024 or shorter keys.** RSA-768 was factored in 2009; RSA-1024 is within reach
+   of well-funded adversaries and is deprecated by every major standards body. Minimum
+   acceptable is RSA-2048; prefer RSA-3072 for new systems or, better, switch to
+   Ed25519/X25519.
+
+2. **PKCS#1 v1.5 padding for RSA encryption.** Bleichenbacher's adaptive
+   chosen-ciphertext attack (1998) allows an attacker who can submit ciphertexts to an
+   RSA decryption oracle to recover plaintext through approximately one million queries.
+   The ROBOT attack (2017) demonstrated that this vulnerability persisted in major TLS
+   implementations nearly 20 years later. Use OAEP (PKCS#1 v2.x) padding exclusively
+   for RSA encryption. For signatures, PSS padding is preferred.
+
+3. **Static Diffie-Hellman (no ephemeral keys).** Using the same DH or ECDH key pair for
+   all sessions eliminates forward secrecy. If the static private key is compromised, all
+   past and future traffic encrypted under that key is decryptable. Always use ephemeral
+   key exchange (ECDHE) -- generate a fresh key pair per session and discard the private
+   key after the shared secret is derived.
+
+4. **Encrypting large payloads directly with RSA.** RSA-2048 with OAEP can encrypt at
+   most 245 bytes per operation (key size minus padding overhead). Attempting to encrypt
+   files, messages, or database records directly with RSA requires chunking, which
+   introduces complexity, potential padding vulnerabilities, and extreme performance
+   penalties. Use hybrid encryption: symmetric cipher for bulk data, RSA/ECC only for
+   encrypting the symmetric key.
+
+5. **Trusting self-signed certificates in production.** A self-signed certificate proves
+   that the presenter possesses the corresponding private key, but provides no identity
+   verification. Without a certificate authority (CA) chain validating the binding between
+   the public key and the claimed identity, any attacker can generate their own
+   self-signed certificate and intercept traffic via man-in-the-middle. Use certificates
+   issued by trusted CAs (Let's Encrypt for public-facing, internal CA for service mesh).
+   Certificate pinning provides additional protection against CA compromise but requires
+   careful rotation planning.
+
+6. **Reusing nonces in ECDSA signing.** ECDSA (unlike EdDSA/Ed25519) requires a unique
+   random nonce k for each signature. If k is reused across two signatures with the same
+   private key, the private key can be algebraically recovered from the two signatures.
+   This is not a theoretical concern -- the Sony PS3 breach (2010) and multiple Bitcoin
+   wallet compromises exploited exactly this flaw. If you must use ECDSA, use RFC 6979
+   deterministic nonce generation. Prefer Ed25519 which is deterministic by design.

package/dist/agents/skills/cursor/security-asymmetric-encryption/skill.yaml

@@ -0,0 +1,42 @@
+name: security-asymmetric-encryption
+version: "1.0.0"
+description: RSA, elliptic curve cryptography (ECDSA, Ed25519, X25519), key exchange (ECDHE), and when to use asymmetric vs symmetric encryption
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-symmetric-encryption
+  - security-hashing-fundamentals
+  - security-hmac-signatures
+  - security-tls-fundamentals
+  - security-certificate-management
+  - owasp-cryptography
+stack_signals: []
+keywords:
+  - RSA
+  - elliptic curve
+  - ECDSA
+  - Ed25519
+  - X25519
+  - ECDHE
+  - key exchange
+  - public key
+  - private key
+  - asymmetric encryption
+  - digital signature
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []