Secp256k1 Security

Security considerations, attack vectors, and best practices for elliptic curve cryptography with secp256k1.

Critical Warnings

⚠️ Zig Implementation NOT Audited The Zig implementation (src/crypto/secp256k1.zig) is:

UNAUDITED - No security review
NOT constant-time - Vulnerable to timing attacks
Educational only - Do not use in production

For production, use:

TypeScript implementation (@noble/curves) - audited
Hardware wallets (Ledger, Trezor)
EVM precompiles (ecRecover)

Private Key Security

Generation

Use cryptographically secure random: ✅ Correct:

// Browser
const privateKey = Bytes32();
crypto.getRandomValues(privateKey);

// Node.js
import crypto from 'crypto';
const privateKey = crypto.randomBytes(32);

// Hardware wallet
// Keys generated in secure hardware, never exported

❌ Never:

// Math.random() is NOT cryptographic
for (let i = 0; i < 32; i++) {
  privateKey[i] = Math.floor(Math.random() * 256); // ❌ INSECURE
}

// Timestamps have low entropy
const timestamp = Date.now();
const hash = keccak256(numberToBytes(timestamp)); // ❌ PREDICTABLE

// User input alone has low entropy
const password = "mypassword123";
const key = keccak256(stringToBytes(password)); // ❌ WEAK

Entropy requirements:

Minimum 256 bits (32 bytes) of cryptographic randomness
Use OS-provided CSPRNG (crypto.getRandomValues)
Hardware RNG preferred (TPM, Secure Enclave)
For offline: dice rolls + hashing (256 rolls * 2.58 bits = 660 bits)

Storage

⚠️ Protect keys at rest: Best practices:

Hardware wallets: Store in Ledger/Trezor, never export
Encrypted keystores: AES-256-GCM with strong KDF (scrypt/argon2)
Secure Enclave: iOS/macOS hardware-backed storage
HSM: Enterprise hardware security modules
Environment isolation: Air-gapped for high-value keys

Avoid:

Plain text files
Environment variables (leak in logs)
Git repositories (permanent history)
Clipboard (malware can read)
Screenshots (OCR readable)
Cloud storage unencrypted
Browser localStorage unencrypted

Key Derivation

Use BIP32/BIP39 for backups:

import * as Bip39 from '@tevm/voltaire/crypto/Bip39';
import * as HDWallet from '@tevm/voltaire/crypto/HDWallet';

// Generate mnemonic (12-24 words)
const mnemonic = Bip39.generateMnemonic(256); // 24 words

// Derive master key
const seed = Bip39.mnemonicToSeed(mnemonic);
const masterKey = HDWallet.fromSeed(seed);

// Derive account keys (BIP44)
const accountKey = HDWallet.derivePath(masterKey, "m/44'/60'/0'/0/0");

// Backup: Write down 24 words, never private keys directly

Nonce Security

RFC 6979 Deterministic Nonces

Why deterministic? Random nonce generation has catastrophic failure modes: ❌ Nonce reuse leaks private key:

Sign message1 with nonce k: s1 = k^-1 * (e1 + r * privkey)
Sign message2 with nonce k: s2 = k^-1 * (e2 + r * privkey)

Solve for privkey:
k = (e1 - e2) / (s1 - s2)
privkey = (s1*k - e1) / r

Real attacks:

PlayStation 3 hack (2010) - Sony reused k=4
Bitcoin theft - Bad RNG in Android wallet (2013)
Blockchain.info bug (2014) - Weak Java SecureRandom

✅ RFC 6979 prevents this:

k = HMAC_DRBG(key: privkey, data: message_hash)

Benefits:

Same (message, key) always produces same nonce
No RNG required
Deterministic = testable
HMAC_DRBG provides cryptographic strength

Implementation Requirements

All implementations MUST:

Use RFC 6979 deterministic nonces
NEVER allow custom nonce input
NEVER reuse nonces across different messages
Validate nonce is in range [1, n-1]

Signature Malleability

Problem

ECDSA signatures have inherent malleability:

// Both signatures verify for same (message, publicKey)
const sig1 = { r, s: s, v: 27 };
const sig2 = { r, s: n - s, v: 28 }; // Malleated

Attacks:

Transaction replay with modified txHash
Smart contract vulnerabilities (signature-based authentication)
Blockchain state inconsistency

Solution: Low-s Enforcement

Ethereum enforces s ≤ n/2 (BIP 62, EIP-2):

const HALF_N = SECP256K1_N >> 1n;

if (s > HALF_N) {
  s = SECP256K1_N - s;  // Normalize to low-s
  v ^= 1;  // Flip recovery ID
}

Our implementation:

sign() always produces low-s
verify() rejects high-s signatures
recoverPublicKey() rejects high-s

Side-Channel Attacks

Timing Attacks

Non-constant-time implementations leak secrets via execution time: ❌ Vulnerable:

// Branch timing leaks bit values
if (bit == 1) {
  result = result + addend;  // Takes longer
}

✅ Constant-time:

// Same timing regardless of bit value
mask = -(bit & 1);  // 0x00000000 or 0xFFFFFFFF
result = result + (addend & mask);  // Always executes

Attack scenario:

Measure signing time for different messages
→ Deduce private key bits from timing variations
→ After ~1000 signatures, recover full key

Mitigations:

Use constant-time libraries (@noble/curves ✅)
Avoid conditional branches on secrets
Use hardware wallets (constant-time guaranteed)
Avoid Zig implementation (⚠️ NOT constant-time)

Power Analysis

Differential Power Analysis (DPA):

Measure CPU power consumption during crypto ops
Correlate power spikes with bit operations
Recover secret keys after many measurements

Simple Power Analysis (SPA):

Single power trace reveals operation sequence
Identify point additions vs doublings
Reconstruct scalar multiplication pattern

Mitigations:

Hardware security (HSM, Secure Enclave)
Power randomization
Constant-time algorithms
Blinding techniques

Cache Timing Attacks

Memory access patterns leak information via cache hits/misses: ❌ Vulnerable:

// Table lookup leaks index via cache timing
value = precomputed_table[secret_index];

✅ Secure:

// Load entire table (constant-time access)
for (int i = 0; i < table_size; i++) {
  mask = -(i == secret_index);
  value |= precomputed_table[i] & mask;
}

Real attacks:

Flush+Reload on AES T-tables
Prime+Probe on RSA/ECC

Message Hashing

Always Hash Before Signing

⚠️ Sign hashes, not raw messages: ❌ Vulnerable:

// Signing raw message allows chosen-plaintext attacks
const signature = Secp256k1.sign(rawMessage, privateKey);

✅ Secure:

// Hash message first (collision-resistant)
const messageHash = Keccak256.hash(rawMessage);
const signature = Secp256k1.sign(messageHash, privateKey);

Why?

ECDSA security requires random-looking messages
Raw messages may have structure attackers exploit
Hashing provides collision resistance
Fixed-length input simplifies validation

Hash Function Requirements

Use collision-resistant hash functions: ✅ Approved:

Keccak256 (Ethereum standard)
SHA-256 (Bitcoin, general use)
SHA-3 (NIST standard)
Blake2b (high performance)

❌ Deprecated:

MD5 (broken - collisions trivial)
SHA-1 (broken - collisions practical)

Public Key Validation

Always Validate Public Keys

⚠️ Verify points are on curve:

function isValidPublicKey(pubkey: Uint8Array): boolean {
  if (pubkey.length !== 64) return false;

  const x = bytesToBigInt(pubkey.slice(0, 32));
  const y = bytesToBigInt(pubkey.slice(32, 64));

  // Check y² = x³ + 7 (mod p)
  const p = SECP256K1_P;
  const y2 = (y * y) % p;
  const x3_plus_7 = (x * x * x + 7n) % p;

  return y2 === x3_plus_7;
}

Attacks if unvalidated:

Invalid curve attacks (point not on secp256k1)
Small subgroup attacks
Twist attacks (point on quadratic twist)

Check for Point at Infinity

// Reject point at infinity (identity element)
if (x === 0n && y === 0n) return false;

Ethereum-Specific Considerations

EIP-155 Replay Protection

Problem: Signatures valid on one chain can be replayed on forks. Solution: Include chainId in v value:

// Pre-EIP-155 (vulnerable to replay)
v = recoveryId + 27;

// Post-EIP-155 (replay protected)
v = chainId * 2 + 35 + recoveryId;

// Examples:
// Ethereum mainnet (chainId=1): v = 37 or 38
// Goerli testnet (chainId=5): v = 45 or 46

ecRecover Gotchas

Precompile behavior:

Returns zero address on invalid signature (NOT error)
Always check return value != 0x0

function verifySigner(bytes32 hash, uint8 v, bytes32 r, bytes32 s, address expected)
  public pure returns (bool)
{
  address signer = ecrecover(hash, v, r, s);

  // ⚠️ Check for zero address (invalid signature)
  if (signer == address(0)) return false;

  return signer == expected;
}

EIP-191 Personal Sign

Prefix prevents signing raw transactions:

// Without prefix: attacker could trick user into signing transaction
const hash = keccak256(transaction);  // ❌ Dangerous

// With prefix: clearly marked as non-transaction message
const prefix = `\x19Ethereum Signed Message:\n${message.length}`;
const hash = keccak256(prefix + message);  // ✅ Safe

Best Practices Summary

DO

✅ Use hardware wallets for high-value keys ✅ Use @noble/curves (audited) for TypeScript ✅ Generate keys with crypto.getRandomValues() ✅ Store encrypted keystores (AES-256-GCM + scrypt) ✅ Validate all inputs (keys, signatures, hashes) ✅ Use RFC 6979 deterministic nonces ✅ Enforce low-s malleability protection ✅ Hash messages before signing ✅ Include EIP-155 chainId in signatures ✅ Use BIP39/BIP32 for backups ✅ Test with official test vectors

DON’T

❌ Use Math.random() for key generation ❌ Reuse nonces across messages ❌ Store private keys unencrypted ❌ Sign raw messages without hashing ❌ Skip public key validation ❌ Use Zig implementation in production (unaudited) ❌ Implement custom crypto (use audited libraries) ❌ Trust user-provided public keys without validation ❌ Ignore signature malleability ❌ Forget EIP-155 replay protection

Security Checklist

Signing - ECDSA signing implementation
Verification - Signature verification
Test Vectors - Validation test cases
HD Wallet - BIP32 key derivation
Bip39 - Mnemonic seed phrases
RFC 6979 - Deterministic ECDSA

Overview

Getting Started

Core Concepts

Skills

JSONRPCProvider

Contract

Primitives

Cryptography

EVM

Utils

Guides

Examples

Swift

Zig

Developer Documentation

Generated API (TypeDoc)

​Secp256k1 Security

​Critical Warnings

​Private Key Security

​Generation

​Storage

​Key Derivation

​Nonce Security

​RFC 6979 Deterministic Nonces

​Implementation Requirements

​Signature Malleability

​Problem

​Solution: Low-s Enforcement

​Side-Channel Attacks

​Timing Attacks

​Power Analysis

​Cache Timing Attacks

​Message Hashing

​Always Hash Before Signing

​Hash Function Requirements

​Public Key Validation

​Always Validate Public Keys

​Check for Point at Infinity

​Ethereum-Specific Considerations

​EIP-155 Replay Protection

​ecRecover Gotchas

​EIP-191 Personal Sign

​Best Practices Summary

​DO

​DON’T

​Security Checklist

​Related