Public key cryptography is the branch of cryptography that uses a pair of mathematically linked keys, one kept secret and one shared openly, and it is the foundation of ownership on every public blockchain. Without it, there would be no way to control coins on a ledger that anyone in the world can read.
Most users never see the mathematics, yet it shapes everything from how addresses look to why a lost seed phrase cannot be recovered. This article explains key pairs, elliptic curves and address derivation in plain terms, and highlights the practical security lessons that follow from how the system works.
The Idea That Made Blockchains Possible
Before public key cryptography, two people who wanted to communicate securely had to share a secret key in advance. That works for a small group but fails for a global network of strangers who will never meet or exchange secrets privately.
Public key cryptography solves the problem by splitting the key in two. The private key stays with its owner, while the public key can be published freely. Data processed with one key can be checked or reversed with the other, depending on the scheme in use.
Blockchains use this split to define ownership. Coins are assigned to something derived from a public key, and only the holder of the matching private key can authorize moving them. No bank, administrator or password reset sits in between, which is both the strength and the risk of the model.
Key Pairs and One-Way Mathematics
A key pair is generated by first choosing a private key, which is simply a very large random number, and then computing the public key from it. The calculation is easy in one direction and, as far as anyone knows, infeasible to reverse.
This asymmetry is the heart of the system. Anyone can derive a public key from a private key in a fraction of a second, but deriving the private key from a public key would require more computation than all existing computers could perform in any meaningful timeframe.
The security therefore depends on two things: the mathematical problem staying hard, and the private key staying secret and unpredictable. If either assumption fails, through a breakthrough in mathematics or a careless key generation process, the protection disappears regardless of how strong the algorithm looks on paper.
Elliptic Curves in Plain Terms
Bitcoin, Ethereum and many other blockchains use elliptic curve cryptography, which offers strong security with much smaller keys than older systems such as RSA. A short introduction to the main ideas makes the rest of the system easier to understand.
The Curve and Its Points
An elliptic curve is defined by a simple equation, and the points that satisfy it form a mathematical group with a special addition rule. In cryptography the curve is defined over a finite field, so the points are whole-number pairs rather than a smooth line drawn on a graph.
One fixed point, called the generator, is chosen as a starting point for every key on that curve.
Scalar Multiplication
A public key is the generator point added to itself as many times as the private key number specifies. This operation, called scalar multiplication, can be computed quickly with clever shortcuts. Undoing it, which means finding how many additions produced a given point, is the elliptic curve discrete logarithm problem.
No efficient classical method is known for solving that problem on well-chosen curves.
Why secp256k1
Bitcoin chose a curve named secp256k1, and Ethereum adopted the same curve. Its parameters were defined in a published standard and have a simple, transparent structure, which reduces concern that hidden weaknesses were built in deliberately.
Other networks use different curves, such as Ed25519, which offer similar security with different performance and implementation trade-offs.
From Private Key to Address
Users rarely share raw public keys. Instead, they share addresses, which are shorter identifiers derived from public keys. The exact process varies by network, but the general pattern is consistent across most blockchains.
- A wallet generates a private key from a secure source of randomness.
- The wallet computes the public key by scalar multiplication on the curve.
- The public key is hashed, using functions such as SHA-256 and RIPEMD-160 for Bitcoin or Keccak-256 for Ethereum.
- The resulting digest is shortened and encoded, often with a checksum to catch typing errors.
Each step is one-way. An address reveals nothing useful about the private key, and even the public key is not visible until certain address types are spent from. The checksum is a practical safeguard, because it helps wallets detect a mistyped address before funds are sent to the wrong place.
Randomness: Where Keys Are Born
A private key is only secure if it is unpredictable. A 256-bit key space is unimaginably large, but that size means nothing if the key was produced by a weak random number generator that only ever outputs a small, guessable set of values.
Weak randomness has caused real key exposures in the wider software world, including predictable seeds, flawed generators on some devices and so-called brain wallets, where keys were derived from memorable phrases that attackers could guess by trying common words and quotes.
Reputable wallets draw entropy, meaning unpredictable input, from the operating system’s cryptographically secure generator or from dedicated hardware. Users should never create keys from phrases they invented, online key generator pages, or tools that cannot explain where their randomness comes from.
Public Keys Are Public, but Exposure Still Matters
The public key is designed to be shared, and today’s elliptic curve security does not depend on hiding it. Even so, some address formats keep the public key off-chain until the owner spends, adding a modest buffer against future advances in attacking elliptic curves.
Address reuse weakens that buffer and also harms privacy. When one address receives many payments and spends repeatedly, its public key and its full payment history become linked and easy to analyze. Using a fresh address for each payment keeps records harder to connect.
Developers should avoid designs that force users to publish public keys unnecessarily, and wallets should generate new receiving addresses by default. These habits cost little today and help reduce exposure if the mathematical assumptions behind current curves ever weaken.
Encryption Versus Signing on Blockchains
Public key cryptography supports two main operations: encryption, where anyone can lock data that only the private key holder can open, and digital signatures, where the private key holder approves data that anyone can verify.
Public blockchains mostly use signatures. Transactions are signed, not encrypted, which is why their contents are visible to everyone. People sometimes assume that cryptography makes on-chain data private, when in fact it mainly proves who authorized each action.
Encryption still appears around blockchains. Some applications encrypt data before storing it, and some node software encrypts connections between peers using key exchange, a method that lets two parties derive a shared secret over an open network. These uses protect confidentiality, while signatures on the ledger protect authorization.
Deriving Many Keys From One Secret
Managing a separate random key for every address would be impractical, so most modern wallets derive many key pairs from one master secret. The BIP-32 standard describes hierarchical deterministic derivation, which builds a tree of keys from a single seed.
A notable feature is that extended public keys can derive child public keys without any private key. This lets a merchant server generate fresh receiving addresses without holding spending power, a useful separation of duties for businesses.
That convenience carries a risk. An extended public key reveals every address in its branch, which exposes the full transaction history to whoever holds it. In some derivation modes, a leaked extended public key combined with one leaked child private key can expose the parent private key, so extended keys need careful handling.
Misconceptions Worth Correcting
Because public key cryptography is invisible to most users, several misunderstandings circulate widely. Clearing them up helps people make better decisions about their own funds.
- A wallet does not hold coins. It holds keys, while balances live on the blockchain.
- An address is not a password. Sharing it is safe, and it cannot be used to move funds.
- Lost private keys cannot be reset. No authority can recreate a key from an address.
- Longer keys are not automatically safer. Security depends on the algorithm, the curve and the randomness.
- Signing a message is not harmless. Some signed messages grant real permissions.
Correcting these beliefs supports safer behavior. Users who understand that the key is the asset tend to protect backups carefully, scrutinize signature requests, and resist anyone who claims they can restore access to funds after a key has been lost.
Implementation Pitfalls for Developers
Strong mathematics can still fail in weak code. Developers handling keys should rely on established, well-reviewed cryptographic libraries rather than implementing curve arithmetic themselves, because small mistakes can leak keys through timing differences or incorrect edge-case handling.
Side-channel attacks are a particular concern. These attacks infer secrets from indirect signals such as how long an operation takes or how much power a device consumes. Constant-time implementations, which take the same time regardless of the secret, reduce this risk on servers and devices.
Validation matters too. Software should check that received public keys are valid points on the expected curve and reject malformed input. Keys should never appear in logs, error messages, analytics or crash reports, and memory holding keys should be cleared when it is no longer needed.
Preparing for Quantum Computing
A large, error-corrected quantum computer running Shor’s algorithm could solve the discrete logarithm problem efficiently, which would let an attacker compute private keys from public keys. Such a machine does not exist today, and predictions about its arrival differ greatly.
The concern matters for blockchains because ledgers are permanent and migrations are slow. Funds held at addresses whose public keys are already visible would be the first exposed, which is one more reason to avoid address reuse and to follow upgrade discussions on the networks you use.
Standards bodies have published post-quantum algorithms based on different hard problems, and researchers are studying how blockchains could adopt them. Most proposals involve larger keys and signatures, so any transition will involve trade-offs. Users do not need to act today, but awareness helps them respond calmly when changes arrive.
Applying Public Key Concepts Day to Day
For users, the practical lessons are simple. Protect the private key or seed above everything else, generate keys only with reputable wallets that use secure randomness, avoid address reuse when your wallet allows, and remember that anyone claiming they can recover a lost key is likely a scammer.
For developers, depend on vetted libraries, validate keys and inputs, keep secrets out of logs, and treat extended public keys as sensitive data. Document which curve, hash and encoding your system uses so reviewers can confirm each choice.
For security teams, include key generation and storage in every review, not only smart contracts. The mathematics behind public key cryptography is strong, and nearly every practical failure comes from how keys are created, stored or exposed, which is exactly where careful processes make the biggest difference.