What are Public and Private Keys?

Introduction

Public and private keys are the cryptographic foundation of modern wallets. They solve a basic problem that sounds simple until you try to do it on the internet: *how can you prove control without revealing the very secret that gives you control? * In blockchains, the answer is not an account password stored on a company server. It is a keypair: one key that stays secret and one key that can be shared.

This idea matters because wallets are not really vaults that hold coins in the ordinary sense. On systems like Ethereum, the chain holds the ledger, and control comes from the ability to produce valid signatures with the right private key. That is why losing a private key can mean losing control, and why revealing it can hand control to someone else. Once that clicks, addresses, signing, watch-only wallets, hardware wallets, and recovery phrases all fit into one picture.

At a high level, a public/private keypair is generated so that the two keys are mathematically related, but in a one-way direction that is useful for security. The private key is kept secret. The public key is shared. NIST defines this as an asymmetric key pair: two related keys with the property that determining the private key from the public key is computationally infeasible, while the pair still supports operations like signature generation and verification, encryption and decryption, or key agreement, depending on the algorithm.

For wallets, the most important use is usually not encryption. It is authorization. The private key lets you sign. The public key lets others verify that signature. That asymmetry is what lets a decentralized network accept your transaction without ever learning your secret.

How do public/private keys prove control without revealing your secret?

Suppose a blockchain network needs to answer a yes-or-no question: *did the controller of this account really approve this transaction? * If the system required you to send your secret to every validator or node as proof, the system would collapse immediately. Anyone who saw the secret could reuse it. So the problem is not just authentication. It is authentication that does not consume or expose the thing being used to authenticate.

Public-key cryptography solves this by separating roles. The private key is the capability you keep. The public key is the information everyone else can know. A signature made with the private key can be checked using the public key, but checking it does not reveal the private key. In ordinary language, the public key is like a lock design you can show to the world, while the private key is the one object that can produce proofs of control. That analogy explains the separation of public and secret information, but it fails in an important way: physical locks wear out and keys are copied by contact, whereas cryptographic verification is mathematical and can be repeated indefinitely without exposing the secret.

This is the compression point for the whole topic: **the public key is not a weaker version of the private key. It is a different object with a different job. ** The private key creates valid authorizations. The public key lets everyone test those authorizations. The system works because those two jobs can be separated.

NIST’s glossary captures the classical intuition by saying the two keys are very large numbers with a unique mathematical relationship: information encrypted with one can be decrypted only with the other, and vice versa. That description is useful as a broad introduction to asymmetric cryptography. But in wallets, you should keep a more specific picture in mind: most wallet activity is built around digital signatures, not around sending encrypted messages to an address.

What are public and private keys made of and how do they differ?

A key is not magic. It is a parameter used by a cryptographic algorithm. NIST defines a cryptographic key as a parameter that determines the operation of the algorithm so that someone with the key can reproduce, reverse, or verify the operation, while someone without it cannot.

In wallet systems, the private key is usually a very large secret number or a secret byte string. The public key is derived from it according to the rules of the algorithm being used. Different ecosystems use different algorithms and therefore different key formats. Bitcoin and Ethereum are commonly associated with elliptic-curve systems over the curve [secp256k1](https://scribe-topic-id.invalid/foundations.cryptography.curves.secp256k1), whose domain parameters are standardized in SEC 2. Solana account addresses are 32-byte values and may be Ed25519 public keys. Ed25519 itself is specified in RFC 8032 as an instance of EdDSA, a signature system based on Edwards curves.

That variety can make the subject look more fragmented than it is. The invariant is simple: there is some private value that must remain secret, and some corresponding public value that others can use to verify signatures or derive identifiers. The curve, encoding, and signature formula may change across ecosystems, but the security model stays recognizable.

This is also where a common misunderstanding appears. People often say a wallet address is a public key. Sometimes that is approximately true, but often it is not exactly true. On Ethereum, the public address for an externally owned account is derived by taking the last 20 bytes of the Keccak-256 hash of the public key and prefixing it with 0x. So the address is derived from the public key, not identical to it. On Bitcoin, addresses are also derived forms rather than raw public keys in most everyday use. On Solana, many account addresses are Ed25519 public keys, but some are program-derived addresses, which are a different mechanism. So the clean relationship is: private key → public key → often some address or account identifier derived from that public information.

How does a blockchain use a keypair to authorize and verify transactions?

The easiest way to see the mechanism is to follow a transaction from intent to verification.

Imagine Alice has a wallet controlling an Ethereum externally owned account. Her wallet software generated a random private key when the account was created, and from that private key it derived the corresponding public key. From the public key, it derived the address that other people use when sending funds to her. That address is public because it is only an identifier; it does not grant spending power.

Now Alice wants to send funds. Her wallet constructs a transaction containing details such as the destination, amount, and nonce. That nonce matters because Ethereum uses it as a transaction counter so that only one transaction with a given nonce can execute for an account, which prevents replay of the same signed transaction as if it were new. The wallet then signs the transaction with Alice’s private key. It does not place the private key into the transaction. It produces a signature: a mathematical proof that the holder of the private key approved this exact message.

When the network receives the transaction, nodes verify the signature using the public-key relationship implied by the transaction and account model. If the signature checks out, the nonce is correct, and the rest of the transaction is valid, the network accepts it. At no point did Alice need to reveal the private key. That is the mechanism that turns a secret into public, machine-checkable authorization.

The same pattern appears beyond Ethereum even when the account model changes. In Bitcoin, control of spendable outputs is usually demonstrated through signatures that satisfy the locking conditions on those outputs. In Solana, many addresses are Ed25519 public keys, and signatures authorize actions at the transaction level while the runtime’s account ownership rules determine what programs may modify. The surrounding machinery differs, but the cryptographic heart is the same: private key to authorize, public key to verify.

Why is it safe to share a public key but not a private key?

A natural question is: if the public key is mathematically related to the private key, why is sharing it safe?

The answer is that these systems are designed so the relationship is easy in one direction and infeasible in the other. NIST states this directly for public-key cryptography: determining the private key from the public key is computationally infeasible. “Infeasible” matters more than “impossible.” This is an engineering security claim, not a metaphysical one. It means that with the intended algorithms and parameters, recovering the private key from the public key should require more computation than realistic attackers can perform.

That assumption depends on choices. It depends on the algorithm, the curve or domain parameters, key generation quality, implementation correctness, and the attacker model. SEC 2, for example, standardizes named elliptic curves and their parameters, including secp256k1. RFC 8032 defines Ed25519 and Ed448 with precise rules for key derivation, encoding, signing, and verification. If those choices are poorly made, the public/private separation can fail. So the distinction between the keys is fundamental, but the exact mathematics underneath it is a design choice.

This is also why public keys need integrity even if they do not need secrecy. NIST’s key-management guidance emphasizes that private and secret keys require protection against unauthorized disclosure, and that all keys require protection against modification. If an attacker can swap a legitimate public key for their own, the system may still verify signatures correctly; just not for the person you thought you were dealing with.

How should private keys be generated and stored to stay secure?

The mathematics is only half the story. The other half is lifecycle management.

A private key is only as trustworthy as the process that generated and stored it. If the randomness used to create it is weak, an attacker may guess or reconstruct it. If the device storing it leaks it, cryptography cannot save you. NIST’s SP 800-57 treats key management as a full lifecycle: secure generation, storage, distribution or establishment, use, backup or archive, recovery, revocation, and destruction. That framing is especially useful for wallets because users often think only about the signing moment, when in practice most failures happen before or around it.

A simple wallet app illustrates this. Most Ethereum libraries generate a random private key when creating an account. That raw secret may then be encrypted with a password for local storage. A hardware wallet pushes the protection boundary further by keeping the private key inside a dedicated device so the host computer does not directly handle it. That is a strong improvement, but it does not solve every problem. Research on clipboard-meddling attacks such as EthClipper shows the limit clearly: even if the private key never leaves the hardware wallet, malware can still try to swap the recipient address and rely on the user to miss the difference during verification. In other words, private-key isolation protects the signing secret, but not every part of the human workflow around what is being signed.

That distinction matters because people sometimes treat “my private key is in hardware” as equivalent to “my transaction is safe.” It is not. The device can prove who approved a transaction, but the user still needs confidence about what they approved.

Why do wallets derive many keys from a single seed (HD wallets)?

If all you ever needed were a single private key and a single public key, wallet backup would be awkward and wallet organization would be brittle. Every new receive address would require a new backup strategy. That is why deterministic wallets became so important.

The basic idea is that a wallet can derive many keypairs from one seed. Bitcoin developer documentation distinguishes simpler single-chain deterministic wallets from hierarchical deterministic, or HD, wallets. The stronger and more flexible model is HD derivation, standardized in BIP 32.

BIP 32 extends the ordinary keypair concept by attaching a 32-byte chain code to the key, creating an extended private key (k, c) and an extended public key (K, c), where K = point(k). The chain code is not a replacement for the key. It is extra entropy that makes deterministic derivation work in a tree structure. From one parent key, the wallet can derive children; from those children, grandchildren; and so on. The result is a hierarchy of related keys rather than a pile of unrelated ones.

This solves a real operational problem. A merchant can generate many receive addresses from a public branch without loading spending keys onto the web server. An auditor can monitor incoming funds using an extended public key. A hardware wallet can keep the extended private side offline while exporting only what is needed for address generation. BIP 32 explicitly describes the “neutered” form N((k, c)) -> (K, c), which removes signing ability while preserving the ability to derive certain public descendants.

Here the public/private distinction becomes more nuanced. An ordinary public key is usually safe to share widely. An extended public key, often serialized as an xpub, carries more structure and therefore deserves more care. BIP 32 warns about a critical weakness of non-hardened derivation: knowledge of a parent extended public key plus any non-hardened descendant private key is equivalent to knowing the parent extended private key, which compromises the whole subtree. That is why HD wallets distinguish between non-hardened and hardened derivation. Non-hardened branches permit useful public derivation. Hardened branches cut off that path to limit what can be inferred if something leaks.

So even within “public” and “private,” there are layers of capability. A public key might identify and verify. An extended public key might additionally derive families of child public keys. A private key might sign for one address. An extended private key might generate an entire wallet branch. The core asymmetry remains, but wallet architecture builds richer roles on top of it.

How do recovery phrases relate to private keys and wallet recovery?

Recovery phrases often confuse people because they seem to replace private keys. They do not. They are a human-friendly way to encode the entropy from which wallet keys can be deterministically derived.

BIP 39 specifies a standard mnemonic scheme. A mnemonic sentence encodes ENT bits of entropy, where ENT is 128 to 256 bits, plus a checksum. The bits are split into 11-bit groups that map onto a 2048-word list, producing phrases such as 12 or 24 words. That sentence can then be converted into a 512-bit binary seed using PBKDF2-HMAC-SHA512 with the mnemonic as the password and `

How do you secure your crypto setup before trading?

Secure your setup by turning the public/private key concepts in the article into a short operational checklist you can follow on Cube Exchange. Cube uses a non-custodial MPC model for signing, so these steps focus on seed handling, extended-key caution, device verification, and small test transfers before you move significant value.

1. Create or import a non-custodial MPC wallet on Cube and record your BIP39 recovery phrase offline (write the 12/24 words on paper). Treat the phrase as the single seed for all derived keys and never store it in plain text.
2. Export only neutered extended public keys (xpub) when you need read-only address generation; never export or share extended private keys (xprv) or raw private keys from any device.
3. Use a dedicated signing device or hardware wallet for approvals when possible and always confirm the transaction details (recipient, amount, and nonce) on that device before you approve a signature.
4. Perform a small test transfer on-chain to verify address derivation, on-chain receipt, and that the signing flow shows the expected public key/address mapping.
5. Before any large trade or withdrawal, verify the destination address on an independent device (compare start/end characters or QR), then approve the final signed transaction in Cube's signing prompt.