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

Try it Live

Run Secp256k1 examples in the interactive playground

This page is a placeholder. All examples on this page are currently AI-generated and are not correct. This documentation will be completed in the future with accurate, tested examples.

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

Point Operations Performance

⌘I

Overview

Getting Started

Core Concepts

Skills

JSONRPCProvider

Contract

Primitives

Cryptography

EVM

Utils

Guides

Examples

Swift

Zig

Developer Documentation

Generated API (TypeDoc)

Try it Live

​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

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