next.orly.dev/.claude/skills/elliptic-curves/references/security.md

Elliptic Curve Security Analysis

Security properties, attack vectors, and mitigations for elliptic curve cryptography.

The Discrete Logarithm Problem (ECDLP)

Definition

Given points P and Q = kP on an elliptic curve, find the scalar k.

Security assumption: For properly chosen curves, this problem is computationally infeasible.

Best Known Attacks

Generic Attacks (Work on Any Group)

Attack	Complexity	Notes
Baby-step Giant-step	O(√n) space and time	Requires √n storage
Pollard's rho	O(√n) time, O(1) space	Practical for large groups
Pollard's lambda	O(√n)	When k is in known range
Pohlig-Hellman	O(√p) where p is largest prime factor	Exploits factorization of n

For secp256k1 (n ≈ 2²⁵⁶):

• Generic attack complexity: ~2¹²⁸ operations
• Equivalent to 128-bit symmetric security

Curve-Specific Attacks

Attack	Applicable When	Mitigation
MOV/FR reduction	Low embedding degree	Use curves with high embedding degree
Anomalous curve attack	n = p	Ensure n ≠ p
GHS attack	Extension field curves	Use prime field curves

secp256k1 is immune to all known curve-specific attacks.

Side-Channel Attacks

Timing Attacks

Vulnerability: Execution time varies based on secret data.

Examples:

• Conditional branches on secret bits
• Early exit conditions
• Variable-time modular operations

Mitigations:

• Constant-time algorithms (Montgomery ladder)
• Fixed execution paths
• Dummy operations to equalize timing

Power Analysis

Simple Power Analysis (SPA): Single trace reveals operations.

• Double-and-add visible as different power signatures
• Mitigation: Montgomery ladder (uniform operations)

Differential Power Analysis (DPA): Statistical analysis of many traces.

• Mitigation: Point blinding, scalar blinding

Cache Attacks

FLUSH+RELOAD Attack:

1. Attacker flushes cache line containing lookup table
2. Victim performs table lookup based on secret
3. Attacker measures reload time to determine which entry was accessed

Mitigations:

• Avoid secret-dependent table lookups
• Use constant-time table access patterns
• Scatter tables to prevent cache line sharing

Electromagnetic (EM) Attacks

Similar to power analysis but captures electromagnetic emissions.

Mitigations:

• Shielding
• Same algorithmic protections as power analysis

Implementation Vulnerabilities

k-Reuse in ECDSA

The Sony PS3 Hack (2010):

If the same k is used for two signatures (r₁, s₁) and (r₂, s₂) on messages m₁ and m₂:

s₁ = k⁻¹(e₁ + rd) mod n
s₂ = k⁻¹(e₂ + rd) mod n

Since k is the same:
s₁ - s₂ = k⁻¹(e₁ - e₂) mod n
k = (e₁ - e₂)(s₁ - s₂)⁻¹ mod n

Once k is known:
d = (s₁k - e₁)r⁻¹ mod n

Mitigation: Use deterministic k (RFC 6979).

Weak Random k

Even with unique k values, if the RNG is biased:

• Lattice-based attacks can recover private key
• Only ~1% bias in k can be exploitable with enough signatures

Mitigations:

• Use cryptographically secure RNG
• Use deterministic k (RFC 6979)
• Verify k is in valid range [1, n-1]

Invalid Curve Attacks

Attack: Attacker provides point not on the curve.

• Point may be on a weaker curve
• Operations may leak information

Mitigation: Always validate points are on curve:

Verify: y² ≡ x³ + ax + b (mod p)

Small Subgroup Attacks

Attack: If cofactor h > 1, points of small order exist.

• Attacker sends point of small order
• Response reveals private key mod (small order)

Mitigation:

• Use curves with cofactor 1 (secp256k1 has h = 1)
• Multiply received points by cofactor
• Validate point order

Fault Attacks

Attack: Induce computational errors (voltage glitches, radiation).

• Corrupted intermediate values may leak information
• Differential fault analysis can recover keys

Mitigations:

• Redundant computations with comparison
• Verify final results
• Hardware protections

Signature Malleability

ECDSA Malleability

Given valid signature (r, s), signature (r, n - s) is also valid for the same message.

Impact: Transaction ID malleability (historical Bitcoin issue)

Mitigation: Enforce low-S normalization:

if s > n/2:
    s = n - s

Schnorr Non-Malleability

BIP-340 Schnorr signatures are non-malleable by design:

• Use x-only public keys
• Deterministic nonce derivation

Quantum Threats

Shor's Algorithm

Threat: Polynomial-time discrete log on quantum computers.

• Requires ~1500-2000 logical qubits for secp256k1
• Current quantum computers: <100 noisy qubits

Timeline: Estimated 10-20+ years for cryptographically relevant quantum computers.

Migration Strategy

1. Monitor: Track quantum computing progress
2. Prepare: Develop post-quantum alternatives
3. Hybrid: Use classical + post-quantum in transition
4. Migrate: Full transition when necessary

Post-Quantum Alternatives

• Lattice-based signatures (CRYSTALS-Dilithium)
• Hash-based signatures (SPHINCS+)
• Code-based cryptography

Best Practices

Key Generation

DO:
- Use cryptographically secure RNG
- Validate private key is in [1, n-1]
- Verify public key is on curve
- Verify public key is not point at infinity

DON'T:
- Use predictable seeds
- Use truncated random values
- Skip validation

Signature Generation

DO:
- Use RFC 6979 for deterministic k
- Validate all inputs
- Use constant-time operations
- Clear sensitive memory after use

DON'T:
- Reuse k values
- Use weak/biased RNG
- Skip low-S normalization (ECDSA)

Signature Verification

DO:
- Validate r, s are in [1, n-1]
- Validate public key is on curve
- Validate public key is not infinity
- Use batch verification when possible

DON'T:
- Skip any validation steps
- Accept malformed signatures

Public Key Handling

DO:
- Validate received points are on curve
- Check point is not infinity
- Prefer compressed format for storage

DON'T:
- Accept unvalidated points
- Skip curve membership check

Security Checklist

Implementation Review

• All scalar multiplications are constant-time
• No secret-dependent branches
• No secret-indexed table lookups
• Memory is zeroized after use
• Random k uses CSPRNG or RFC 6979
• All received points are validated
• Private keys are in valid range
• Signatures use low-S normalization

Operational Security

• Private keys stored securely (HSM, secure enclave)
• Key derivation uses proper KDF
• Backups are encrypted
• Key rotation policy exists
• Audit logging enabled
• Incident response plan exists

Security Levels Comparison

Curve	Bits	Symmetric Equivalent	RSA Equivalent
secp192r1	192	96	1536
secp224r1	224	112	2048
secp256k1	256	128	3072
secp384r1	384	192	7680
secp521r1	521	256	15360

References

• NIST SP 800-57: Recommendation for Key Management
• SEC 1: Elliptic Curve Cryptography
• RFC 6979: Deterministic Usage of DSA and ECDSA
• BIP-340: Schnorr Signatures for secp256k1
• SafeCurves: Choosing Safe Curves for Elliptic-Curve Cryptography