Public Keys and Private Keys

Blockchain systems use asymmetric cryptography (also called public-key cryptography) as the foundation for identity, ownership, and transaction authorization. Every participant in a blockchain network is identified not by a name or account number issued by an authority, but by a cryptographic key pair they generate themselves. Understanding how these keys work is essential to understanding how blockchains secure trillions of dollars in value without a centralized identity provider.

Asymmetric Cryptography: The Concept

In symmetric cryptography, the same key is used to encrypt and decrypt data. Both parties must share this key in advance through a secure channel—a practical challenge at scale. Asymmetric cryptography solves this by using two mathematically related but functionally distinct keys:

• Private key: A secret value known only to its owner. It is used to sign data and must never be shared.
• Public key: A value derived from the private key that can be freely shared. It is used to verify signatures and derive the wallet address.

The critical property is that while the public key is derived from the private key, it is computationally infeasible to reverse the process—you cannot determine the private key from the public key. This one-way relationship is based on mathematical problems believed to be intractable with current computing technology.

Key Generation

The process of generating a key pair in most blockchain systems follows these steps:

1. Generate a private key: A 256-bit random number is selected from a cryptographically secure random number generator. The security of the entire system depends on the quality of this randomness. A predictable or biased random number generator would allow attackers to guess private keys.
2. Derive the public key: The private key is used as input to an elliptic curve multiplication operation. Most blockchains (Bitcoin, Ethereum) use the secp256k1 elliptic curve. The private key k is multiplied by the curve's generator point G to produce the public key K = k × G. This multiplication is easy to compute but impossible to reverse (the elliptic curve discrete logarithm problem).
3. Derive the address: The public key is hashed (using Keccak-256 on Ethereum, or SHA-256 followed by RIPEMD-160 on Bitcoin) and truncated to produce the wallet address. This adds another layer of indirection: even the public key is not directly exposed on the blockchain until the address's owner signs a transaction.

The Relationship Between Keys

The derivation is strictly one-directional: Private Key → Public Key → Address. You cannot go backward at any step.

Digital Signatures

Digital signatures are the mechanism by which private keys authorize transactions without being revealed. The process uses the Elliptic Curve Digital Signature Algorithm (ECDSA) on most blockchains (Ethereum is transitioning to also support EdDSA via account abstraction).

Signing a Transaction

1. The transaction data (recipient, amount, gas parameters, nonce, etc.) is serialized and hashed to produce a fixed-size message digest.
2. The private key and the message digest are input to the ECDSA signing algorithm, which produces a signature consisting of two values, r and s, plus a recovery identifier v.
3. The signature is attached to the transaction and broadcast to the network.

Verifying a Signature

1. Any node receiving the transaction can take the signature (r, s, v) and the transaction hash and mathematically recover the public key of the signer.
2. The node then derives the address from this recovered public key.
3. If the derived address matches the transaction's from field, the signature is valid—the transaction was authorized by the holder of the corresponding private key.

This process proves ownership without exposing the private key. The signer demonstrates knowledge of the private key through a mathematical proof that can be verified by anyone but forged by no one.

The keyspace and Brute-Force Resistance

A 256-bit private key has 2²⁵⁶ possible values. To put this number in perspective:

• 2²⁵⁶ ≈ 1.16 × 10⁷⁷
• The estimated number of atoms in the observable universe is approximately 10⁸⁰

If every computer on Earth (approximately 10¹⁰ devices) could check one billion keys per second (10⁹), it would take approximately 10⁵⁸ seconds—or roughly 3.7 × 10⁵⁰ years—to enumerate half the keyspace. The sun will burn out roughly 10⁴⁰ times before that happens. Brute-forcing a 256-bit private key is not merely difficult; it is physically impossible with known technology.

Security Implications and Risks

While the cryptography itself is robust, real-world key security failures almost always stem from operational mistakes:

• Weak randomness: If the random number generator used to create the private key is flawed, attackers can predict or narrow down the key. This has led to real losses—certain early Android Bitcoin wallets used a flawed RNG that allowed key recovery.
• Key exposure: Storing private keys in unencrypted files, copying them to clipboards, or entering them into phishing sites.
• Nonce reuse in ECDSA: The ECDSA algorithm requires a unique random nonce for each signature. If the same nonce is used twice with the same private key, the private key can be algebraically recovered from the two signatures. This vulnerability was exploited in the 2010 Sony PlayStation 3 signing key compromise.
• Quantum computing: Shor's algorithm, if implemented on a sufficiently large quantum computer, could theoretically break the elliptic curve discrete logarithm problem. This remains a long-term concern rather than an imminent threat, and post-quantum cryptographic schemes are under active development.