About

Ethereum wallet security begins with key generation. A private key is a random 256-bit integer k in the range 1 ≤ k < n, where n is the order of the secp256k1 curve (1.158 × 10⁷⁷). Weak randomness in this step has caused real fund losses - the "blockchain bandit" exploited wallets generated from low-entropy keys and drained over $54 million. This tool uses crypto.getRandomValues() (CSPRNG) to produce keys with full 256-bit entropy. The public key is derived via elliptic curve point multiplication K = k ⋅ G on the secp256k1 curve, and the address is the last 20 bytes of the Keccak-256 hash of the uncompressed public key. All operations execute in your browser. No private key data is transmitted over any network.

This generator also produces BIP-39 mnemonic phrases (12 or 24 words) for human-readable backup. The tool implements EIP-55 mixed-case checksum encoding, which catches 99.986% of address transcription errors. Limitation: this tool generates raw key pairs. It does not interact with the Ethereum network, broadcast transactions, or query balances. For hardware-level security, transfer generated keys to a cold storage device.

Formulas

The wallet generation pipeline follows three cryptographic stages:

K = k ⋅ G

where k is the private key (random 256-bit integer), G is the secp256k1 generator point, and K is the resulting public key point (x, y). The multiplication is scalar point multiplication on the elliptic curve defined by:

y² ≡ x³ + 7 (mod p)

The Ethereum address A is derived by hashing the uncompressed public key (excluding the 04 prefix byte) with Keccak-256 and taking the rightmost 20 bytes:

A = Keccak256(K_x || K_y)[12:]

For EIP-55 checksum encoding, each hex character at position i is uppercased if the corresponding nibble of Keccak256(lowercase address)[i] ≥ 8. BIP-39 mnemonic generation converts entropy bits to word indices via 11-bit segmentation after appending a SHA-256 checksum of length ENT32 bits, where ENT is the initial entropy length in bits.

Reference Data

Parameter	Value	Description
Curve	secp256k1	Elliptic curve used by Ethereum and Bitcoin
Field Prime p	2²⁵⁶ − 2³² − 977	Prime defining the finite field F_p
Curve Order n	FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141	Number of points on the curve
Generator G_x	79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798	x-coordinate of base point
Generator G_y	483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8	y-coordinate of base point
Private Key Length	256 bits (32 bytes)	Random integer in [1, n−1]
Public Key (Uncompressed)	512 bits (65 bytes with 04 prefix)	Point (x, y) on curve
Public Key (Compressed)	264 bits (33 bytes)	x-coordinate + parity byte (02/03)
Address Length	160 bits (20 bytes)	Last 20 bytes of Keccak-256(pubkey)
Hash Algorithm	Keccak-256	SHA-3 variant (pre-NIST, Ethereum standard)
Checksum Standard	EIP-55	Mixed-case hex encoding for error detection
Mnemonic Standard	BIP-39	Entropy → mnemonic word sequence
Mnemonic Wordlist	2048 English words	Standardized by BIP-39 specification
12-Word Entropy	128 bits	Security: ~2¹²⁸ combinations
24-Word Entropy	256 bits	Security: ~2²⁵⁶ combinations
Cofactor h	1	secp256k1 has cofactor 1 (simple group)
Key Space Size	~1.158 × 10⁷⁷	Brute-force infeasible
Address Format	0x + 40 hex chars	Ethereum standard with optional EIP-55 checksum
Collision Probability	~10⁻⁴⁸	Birthday paradox threshold for 160-bit addresses
CSPRNG Source	crypto.getRandomValues()	OS-level entropy (Windows CNG / Linux /dev/urandom)

Frequently Asked Questions

The Elliptic Curve Discrete Logarithm Problem (ECDLP) states that given points K and G on secp256k1, finding the scalar k such that K = k·G requires approximately 2¹²⁸ operations using Pollard's rho algorithm. Current computing capacity makes this infeasible for the foreseeable future. The curve's cofactor of 1 eliminates small-subgroup attacks.

Ethereum's development began before NIST finalized SHA-3. The Keccak team's original submission uses different padding (0x01 vs 0x06) than the final NIST standard. Ethereum adopted the pre-NIST Keccak-256 variant and the ecosystem cannot change this without a hard fork. The security properties are equivalent - both use a 1600-bit state with 24 rounds of the Keccak-f permutation.

A valid private key must satisfy 1 ≤ k < n where n is the curve order (approximately 1.158 × 10⁷⁷). Since the maximum 256-bit integer is 1.158 × 10⁷⁷ × 1.0000000000000000000000000000000000000027, the probability of generating an out-of-range value is roughly 3.73 × 10⁻³⁹. The generator resamples if this occurs, though in practice it effectively never happens.

EIP-55 computes Keccak-256 of the lowercase hex address string. For each hex character at position i: if the corresponding hash nibble is ≥ 8, the character is uppercased. This creates a 60-bit checksum embedded in the casing pattern. Random single-character errors are detected with 99.986% probability. Double errors have slightly lower detection rates depending on position correlation.

Browser-based generation is safe if three conditions are met: (1) the page runs locally or over HTTPS, ensuring crypto.getRandomValues() uses the OS CSPRNG, (2) no network requests transmit key material - this tool makes zero network calls, (3) the browser environment is free of malicious extensions. For high-value storage, generate the wallet on an air-gapped machine and transfer only the address. Print the paper wallet and clear browser storage immediately.

A 12-word mnemonic encodes 128 bits of entropy plus a 4-bit checksum (132 bits total, 12 × 11-bit words). A 24-word mnemonic encodes 256 bits of entropy plus an 8-bit checksum (264 bits total). The 128-bit level resists brute force against classical computers. The 256-bit level additionally resists Grover's algorithm on quantum computers, which halves the effective key length to 128 bits.

Theoretically yes - this is a hash collision on the 160-bit address space. With approximately 2⁸⁰ key generations (birthday paradox bound), a collision becomes likely. At current global computing capacity generating roughly 10⁹ keys per second, reaching 2⁸⁰ would take approximately 3.8 × 10¹³ years. The probability of accidental collision between any two randomly generated wallets is approximately 10⁻⁴⁸.