Asymmetric Cryptography
Asymmetric cryptography uses paired public and private keys for encryption and digital signatures in blockchain.
Key Takeaways
- Asymmetric cryptography uses mathematically linked key pairs: a private key kept secret and a public key shared openly. The private key can produce signatures that anyone can verify with the public key, but the public key cannot reveal the private key.
- Bitcoin relies on elliptic curve cryptography over the secp256k1 curve for all transaction signing: a 256-bit private key generates a public key through one-way scalar multiplication, providing 128-bit security with compact keys.
- Unlike symmetric cryptography where both parties share one secret, asymmetric schemes let strangers transact securely without prior coordination: the mathematical foundation that makes trustless, peer-to-peer digital money possible.
What Is Asymmetric Cryptography?
Asymmetric cryptography (also called public-key cryptography) is a cryptographic system that uses two distinct but mathematically related keys: a private key and a public key. The private key is kept secret by its owner, while the public key can be distributed freely. Data encrypted with one key can only be decrypted with the other, and a signature created with the private key can be verified by anyone holding the corresponding public key.
The concept was publicly introduced by Whitfield Diffie and Martin Hellman in 1976, followed by the first practical implementation (RSA) by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977. Before asymmetric cryptography, all encryption was symmetric: both parties needed the same shared secret, creating a key distribution problem. How do you securely share the key in the first place?
Asymmetric cryptography solves this by eliminating the need for a shared secret. In Bitcoin and other blockchain systems, it serves as the foundation for proving ownership. When you create a wallet, you generate a private key that derives a public key, which in turn derives an address. Spending funds requires producing a digital signature with the private key: a proof that the entire network can verify without ever learning the secret itself.
Asymmetric vs. Symmetric Cryptography
Symmetric cryptography uses a single key for both encryption and decryption. AES-256, the most widely deployed symmetric cipher, is fast and efficient but requires both communicating parties to already possess the same secret key. This works well when you control both endpoints (encrypting a hard drive, for example) but creates a chicken-and-egg problem for communication between strangers.
Asymmetric cryptography trades performance for flexibility. It is roughly 1,000 times slower than symmetric encryption for bulk data, but it solves the key distribution problem entirely. In practice, most secure protocols (TLS, SSH, PGP) use a hybrid approach: asymmetric cryptography to establish a shared secret, then symmetric cryptography for fast bulk encryption.
| Property | Symmetric | Asymmetric |
|---|---|---|
| Keys | One shared secret | Public/private pair |
| Key distribution | Requires secure channel | Public key is freely shared |
| Speed | Fast (AES: ~1 GB/s) | Slow (RSA: ~1 MB/s) |
| Key size for 128-bit security | 128 bits (AES-128) | 256 bits (ECC) or 3,072 bits (RSA) |
| Primary use | Bulk encryption | Signatures, key exchange |
| Bitcoin usage | Not used for core protocol | All transaction signing |
How It Works
Asymmetric cryptography relies on trapdoor functions: mathematical operations that are easy to compute in one direction but computationally infeasible to reverse. The security of every asymmetric system depends on a specific hard mathematical problem that no known algorithm can solve efficiently.
Trapdoor Functions
A trapdoor function is a one-way function with a secret shortcut. Multiplying two large prime numbers is trivial, but factoring the product back into its prime components is extraordinarily difficult for large numbers. This asymmetry between the forward operation (easy) and the reverse operation (hard) is what makes public-key cryptography possible.
Different algorithms use different trapdoor functions:
- RSA: based on the integer factorization problem. Security depends on the difficulty of factoring the product of two large primes.
- Diffie-Hellman / DSA: based on the discrete logarithm problem in finite fields.
- ECC (including Bitcoin's ECDSA and Schnorr signatures): based on the elliptic curve discrete logarithm problem (ECDLP). Given a point P and the result Q = kP on the curve, finding k is infeasible.
Key Generation
In Bitcoin, key generation uses elliptic curve cryptography on the secp256k1 curve:
- Generate a random 256-bit integer as the private key (any number between 1 and the curve order n, approximately 1.158 × 10⁷⁷)
- Compute the public key by multiplying the curve's generator point G by the private key: Public Key = Private Key × G
- The public key is a point on the curve, encoded as either 33 bytes (compressed) or 65 bytes (uncompressed)
# Simplified key generation (conceptual)
private_key = random_256_bit_integer() # Secret: never share
public_key = private_key * G # One-way: cannot reverse
address = HASH160(public_key) # Further one-way derivationThe scalar multiplication (Private Key × G) involves repeated point addition on the elliptic curve. While the forward computation takes microseconds, reversing it (finding the private key from the public key) would require approximately 2¹²⁸ operations with the best known classical algorithms: a number so large that it exceeds the estimated number of atoms in the observable universe.
Signing and Verification
Bitcoin uses asymmetric cryptography for digital signatures, not encryption. When spending Bitcoin:
- The wallet constructs a transaction and computes its hash
- The private key and the transaction hash are fed into the signing algorithm (ECDSA or Schnorr) along with a random nonce to produce a signature
- The signature, public key, and transaction are broadcast to the network
- Every validating node runs the verification algorithm: given the signature, public key, and transaction hash, the algorithm outputs true or false
Verification is fast: a single ECDSA verification on secp256k1 takes roughly 50 microseconds, while Schnorr verification is even faster and supports batch verification where checking multiple signatures together is cheaper than checking them individually.
Common Algorithms
RSA
RSA (Rivest-Shamir-Adleman) was the first widely deployed asymmetric algorithm, published in 1977. Its security relies on the difficulty of factoring the product of two large primes. RSA remains widely used for TLS certificates and email encryption, but its key sizes are large: 3,072 bits for 128-bit security, compared to 256 bits for ECC. This makes RSA impractical for blockchain systems where every transaction signature is stored on thousands of nodes.
ECDSA
The Elliptic Curve Digital Signature Algorithm is Bitcoin's original signature scheme, used for legacy, SegWit, and nested SegWit transactions. ECDSA on secp256k1 produces signatures of 70 to 72 bytes (DER-encoded) using 256-bit keys, delivering equivalent security to RSA-3072 at a fraction of the size.
Schnorr Signatures
Activated with Bitcoin's Taproot upgrade (BIP-340) in November 2021, Schnorr signatures offer several advantages over ECDSA: fixed 64-byte signatures (no DER encoding overhead), provable security under the random oracle model, and native support for key aggregation. Multiple signers can produce a single signature indistinguishable from a solo signature, improving privacy and reducing on-chain footprint.
FROST
FROST (Flexible Round-Optimized Schnorr Threshold Signatures) extends Schnorr to threshold signing, where t-of-n participants can produce a valid signature without any single party holding the complete private key. This enables advanced custody models like those used by Spark, where operators and users share signing authority over virtual UTXOs without any party having unilateral control.
Asymmetric Cryptography in Bitcoin
Every Bitcoin transaction is fundamentally an exercise in asymmetric cryptography. The entire ownership model rests on the assumption that only the private key holder can produce valid signatures for their funds.
- Transaction authorization: spending any UTXO requires a valid signature matching the public key (or script) in the locking condition
- Address derivation: Bitcoin addresses are hashes of public keys, adding a layer of indirection that hides the public key until the first spend
- Multisig and threshold schemes: multiple independent key pairs can be required to authorize a single transaction, distributing trust
- HTLCs and payment channels: the Lightning Network and other layer-2 protocols use asymmetric signatures to enforce conditional payments off-chain
- Message signing: wallets can sign arbitrary messages to prove address ownership without creating a transaction
For a deeper look at how asymmetric cryptography powers Bitcoin's signature schemes, see the research article on Taproot and Schnorr signatures.
Why It Matters
Without asymmetric cryptography, trustless digital money would not exist. Symmetric encryption requires a shared secret between sender and receiver, which means you need a trusted channel to set up that secret. In a decentralized network with thousands of anonymous nodes, there is no such channel.
Asymmetric cryptography allows anyone to verify a transaction's authenticity without trusting anyone. A node in Tokyo can confirm that a signature from a wallet in Buenos Aires is valid, without the two ever communicating directly. This property: verification without shared secrets: is what makes self-custody and censorship resistance possible.
Spark leverages asymmetric cryptography through FROST threshold signatures, enabling shared custody over Bitcoin layer-2 assets where neither the user nor the operator alone can move funds. This approach preserves self-sovereignty while enabling instant, low-cost transactions.
Risks and Considerations
Key Management
Asymmetric cryptography shifts the security burden to the key holder. If the private key is lost, there is no recovery mechanism: the funds are permanently inaccessible. If the key is stolen, the thief gains full control. This makes secure key management and backup (typically via seed phrases) essential.
Nonce Reuse
ECDSA signatures require a unique random nonce for each signing operation. Reusing a nonce across two different signatures with the same private key allows an attacker to algebraically recover the private key. This vulnerability led to significant theft in early Bitcoin history and prompted the adoption of deterministic nonce generation (RFC 6979), which derives the nonce from the message and private key rather than relying on random number generators.
Quantum Computing Threat
Shor's algorithm, running on a sufficiently powerful quantum computer, could solve the elliptic curve discrete logarithm problem in polynomial time, breaking the trapdoor that asymmetric cryptography depends on. A quantum computer with an estimated 2,500+ logical qubits could theoretically recover a Bitcoin private key from its public key.
Current quantum computers operate with fewer than 1,500 noisy physical qubits, far from the millions of error-corrected qubits required for such an attack. However, the threat motivates active research into post-quantum cryptography and lattice-based schemes that resist quantum attacks. Bitcoin's address hashing (exposing only a hash, not the public key, until spending) provides a partial defense: addresses that have never spent funds do not reveal their public key.
Implementation Vulnerabilities
The mathematics of asymmetric cryptography is well-proven, but implementation bugs can be devastating. Side-channel attacks (timing, power analysis, electromagnetic emissions) can leak private key information during signing operations, especially on hardware without constant-time arithmetic. Hardware wallets and secure elements mitigate these risks by performing signing in isolated, tamper-resistant environments.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.