A private key is a secret number that proves control of crypto on a blockchain: a wallet uses it to sign each transaction, and the network accepts the transaction only if the signature checks out against the matching public key. On Bitcoin and Ethereum the key is a 256-bit number, which written out takes 64 hexadecimal characters. The coins never sit inside a wallet. They are entries on a shared ledger, and, as ethereum.org puts it, what you actually hold are private keys. Whoever has the key can spend whatever its addresses hold, with no bank or help desk behind it. The crypto hub covers the wider basics.
How do private keys, public keys and addresses fit together?
The wallet calculates the public key from the private key and the address from the public key, and neither step can be run backward.
Multiplying here means applying the curve's point-addition rule over and over, with shortcuts that keep it quick even for a number up to 78 digits long. Running it in reverse, working out which number produced a given point, is the hard problem the whole system depends on. Bitcoin and Ethereum use the curve known as secp256k1, which NIST's elliptic-curve guidance allows for blockchain-related applications, while Solana uses Ed25519 keys, a scheme NIST's Digital Signature Standard also approves.
| Item | What it is | Typical form | Who should see it | What it lets someone do |
|---|---|---|---|---|
| Private key | A secret random number | 64 hexadecimal characters, or a Base58Check string in Bitcoin's Wallet Import Format | Only you, or your custodian | Sign transactions and move everything at its addresses |
| Public key | A curve point calculated from the private key | 33 bytes in compressed form on Bitcoin, 32 bytes for Ed25519 | Anyone; signing reveals it | Check signatures and derive the address |
| Wallet address | A shortened, error-checked form of the public key or of a spending rule | Starts with 1, 3 or bc1 on Bitcoin; 0x plus 40 hexadecimal characters on Ethereum; Base58 text on Solana | Anyone who pays you | Receive funds and view their public history |
| Seed phrase | The wallet's master randomness, written as words | 12 to 24 words from a list of 2,048 | Only you | Recreate every key and address the wallet derives |
| Extended public key | A public key plus the chain code for one account | A long string starting xpub on Bitcoin | Only trusted software | List every address in the account and its history |
| Device PIN or app password | A lock on one copy of the wallet | A short code or password | Only you | Open that device or app, nothing more |
The private key and the seed phrase are the two items never to share, and the phrase is the more powerful of the two. The PIN is the most misunderstood: it guards one piece of hardware, so a thief holding the phrase does not need it, and neither does an owner restoring onto a new device.
How does a seed phrase relate to a private key?
A seed phrase is not itself a key but the backup from which a wallet calculates all of its keys, so one phrase can stand behind thousands of them.
Under BIP-39, the wallet starts with 128 to 256 random bits, adds a checksum of one bit for every 32, and splits the result into 11-bit chunks, each naming one word from a 2,048-word list: 12 words for 128 bits, 24 for 256. The words, plus any optional passphrase, then go through 2,048 rounds of HMAC-SHA512 to produce a 512-bit seed. BIP-32 turns that seed into a master private key and a chain code, and from those into a tree of child keys. A derivation path names one branch, written under BIP-44 as m / purpose' / coin_type' / account' / change / address_index, with a separate coin type for each network, so the same words yield unrelated keys on Bitcoin and Ethereum. Solana's command-line tools derive Ed25519 keys under SLIP-0010, which hardens every step of the path, according to Anza's documentation for them.
Hardening protects the tree from a specific leak. The Bitcoin developer guide warns that someone holding an extended public key plus any one private key derived from it without hardening can work back to the parent private key and every key below it. Hardened steps block that route, which is why wallets harden the top levels of the path and why an xpub deserves more care than an ordinary public key.
How does a private key sign a transaction?
The wallet reduces the transaction to a short fingerprint, a hash, and combines it with the private key to produce a signature anyone can check with the public key.
- The wallet assembles the transaction: the coins being spent, the recipient, the amount and the fee.
- It hashes those details into a fixed-length fingerprint, so any later edit would change the fingerprint completely.
- Under ECDSA, it picks a one-time secret number, turns it into a point on the curve, and mixes in the fingerprint and the private key to get two numbers, r and s, which together are the signature.
- Every node checks r and s against the public key and the fingerprint. Alter a single byte, such as the amount, and the check fails.
The one-time number is the weak point. NIST's Digital Signature Standard requires a new one for every signature and warns that insufficient randomness in it would reveal a private key. Deterministic ECDSA, described in RFC 6979, and EdDSA, the family Ed25519 belongs to, compute that number from the private key and the message instead, so a poor random number generator cannot spoil a signature. On Ethereum, anyone can derive the signer's public key from a signature, ethereum.org explains, which proves who sent the transaction without a separate identity check.
How are private keys lost or stolen?
Keys are almost never cracked by brute force; they leak through weak randomness, malware and deception, or vanish with a device that was never backed up.
Worked example: Why a random key holds and a weak one falls
- Bitcoin and Ethereum accept any whole number from 1 to just under 2²⁵⁶ as a private key, about 1.16 × 10⁷⁷ choices.
- Suppose an attacker could test keys as fast as the whole Bitcoin network computes hashes, about 1,046 exahashes a second (EH/s), or about 10²¹ a second. That is generous, since mining machines compute hashes rather than keys.
- Checking half of all possible keys at that speed would take about 1.8 × 10⁴⁸ years. Even a 12-word phrase, with 2¹²⁸ or about 3.4 × 10³⁸ combinations, would hold out for about 5.4 billion years on average.
- Randomness limited to 32 bits leaves only 4,294,967,296 possibilities. At an assumed 100,000 guesses a second, one computer would get through all of them in about 12 hours.
Real failures look like the last line, not the first:
- Weak randomness. On August 11, 2013, bitcoin.org warned that a flaw in Android's secure random number generator left every wallet generated by an Android app open to theft, and told users to move their coins to newly generated addresses. A decade later, the National Vulnerability Database recorded that Libbitcoin Explorer's bx seed command drew on just 32 bits of randomness (CVE-2023-39910), and wallets made with it were drained in mid-2023.
- Deception. Federal prosecutors say that on August 18, 2024, callers posing as Google and exchange support staff talked a Washington, D.C. resident into opening files holding private keys to more than 4,100 bitcoin, then worth over $230 million, while a co-conspirator used the access to take the coins. The bitcoin price page shows what that many coins are worth today, and crypto scams covers the scripts such callers use.
- Malware and phishing. A key on an internet-connected device is exposed to cyberthreats, the SEC's custody bulletin notes, and any copy of a key or phrase kept online is only as safe as the account or device holding it. How to store crypto safely covers offline backups, and hot vs cold wallets covers tampered devices.
- Loss. The same bulletin warns that losing a private key means losing access to the assets for good. A seed phrase backup prevents that, but a forgotten optional passphrase silently leads to a different wallet, and heirs without instructions face the same wall; crypto inheritance planning deals with that case.
What does custody of a private key mean?
Custody means control of the keys: whoever can sign for the coins holds them, whatever an account screen shows.
The SEC's December 2025 investor bulletin sorts holdings into two kinds. In self-custody you have sole control of the private keys and sole responsibility for them. With third-party custody, an exchange or specialist custodian controls the keys and keeps them in hot wallets, cold wallets or both. The bulletin warns that a custodian that is hacked, shuts down or goes bankrupt can leave customers without access, and that some lend out deposited assets, a practice called rehypothecation, or commingle them. An exchange balance is therefore a claim on the company's books, and proof of reserves is one way platforms try to show that the coins behind those claims exist. Custodial vs non-custodial wallets compares the two arrangements, and whether crypto is safe on an exchange covers what happens when a platform fails.
Control can also be split. A multisig wallet needs signatures from several separate keys, such as 2 of 3, while a wallet built on multi-party computation divides the signing secret into shares held on separate devices or by separate parties, so no single share can sign. On Ethereum, a smart contract account has no private key at all, ethereum.org notes; it is controlled by the logic of its code.
How is a private key different from a password?
A password is checked by a company and can be reset; a private key is checked by every node on the network and cannot be reset by anyone.
The SEC bulletin likens a private key to a password and a public key to an email address, a helpful start that breaks down at recovery. A leaked password can be changed and the account kept, while a leaked key cannot, so the coins have to move to a new one. A forgotten password goes to customer support; a lost key with no backup has nowhere to go. Three other terms add to the confusion. An exchange API key is a credential for an account, issued by the platform and revocable there, not a blockchain key. Ethereum validators use separate BLS keys to take part in consensus. And a keystore file is a private key encrypted with a password, so it is only as strong as that password.