Public-key cryptography in plain terms

Two related keys with different jobs

Public-key cryptography is a family of techniques built around a mathematical relationship between two keys. A private key is secret information held by an authorized signer. A corresponding public key can be shared so that other parties can verify cryptographic claims made with the private key. In digital-asset networks, the most visible application is usually a digital signature rather than encryption. A participant authorizes a defined message with a private key, and anyone following the protocol can check the resulting signature with the public key. The verification does not require the verifier to possess, request, or reconstruct the private key. This separation supports open verification on systems in which many parties do not know or trust one another.

A key is not a physical key, account password, legal identity, or token balance. It is a value used by a cryptographic algorithm. The private key must be chosen from an allowed range and protected from disclosure. The public key is obtained through the algorithm's defined calculation. A correct implementation makes that forward calculation practical while making recovery of the private key from the public key computationally infeasible with the currently assumed attack capabilities. Public keys may be visible in transactions or stored as part of account information, but the timing and form of disclosure depend on the network and output type.

The intuition behind asymmetric mathematics

Symmetric cryptography uses the same shared secret for operations such as encryption and decryption. Public-key, or asymmetric, cryptography uses mathematically linked public and private information. A simple classroom analogy is a one-way turnstile: it is easy to move through in the permitted direction but very difficult to reverse. The analogy is incomplete because real schemes are precise algorithms with assumptions, parameters, and failure modes. What matters is that verification can be public without giving every verifier the power to produce signatures. Never use the analogy as proof that the underlying mathematics is literally irreversible.

Elliptic curves, briefly

Many networks use elliptic-curve cryptography, which performs arithmetic on specially chosen sets of points. A private key is typically represented as a number; applying a defined operation with a standard base point yields a public key. The details require mathematics beyond this foundation module. Learners do not need to calculate points by hand, but should know that a curve name identifies specific parameters rather than a general marketing category. Two networks can use different curves or signature methods even if both describe their systems as “public-key cryptography.”

Bitcoin's traditional elliptic-curve digital signatures use ECDSA with the secp256k1 curve; its Taproot design also supports Schnorr signatures specified by Bitcoin Improvement Proposal (BIP) 340. Ethereum externally owned accounts conventionally use secp256k1-based ECDSA to authorize transactions. Solana keypairs commonly use Ed25519, an Edwards-curve signature system. These are examples of different technical choices, not a ranking of networks. An algorithm name, curve name, public-key representation, and address format are distinct facts that analysts should avoid combining into a single label.

What public verification establishes

If a signature verifies for a given message and public key, the verifier has evidence that the signature was produced using signing capability associated with the matching private key, under the scheme's assumptions. It does not automatically reveal the person's name, employer, legal authority, intent, or reason for signing. A key can be operated by a person, a device, a service, or a coordinated group, and access may change over time. Authentication of a cryptographic key is therefore not the same as proof of a human identity or organizational approval. A legal claim of attribution requires separate facts and applicable law.

This distinction is especially important to managers, investigators, and public-sector staff. Suppose an organization lists an address on a public website and later observes a valid transaction signed by its associated key. That proves something narrow about control over the signing capability when the message was authorized; the website statement may still be mistaken, outdated, or unauthorized. Conversely, an employee may have had legitimate technical access but no authority to approve a particular transaction. Technical capability, organizational authorization, and legal responsibility should be evaluated separately.

Key generation and security assumptions

Cryptographic strength is not determined by a key's length in characters alone. The algorithm, mathematical parameters, generation process, implementation, and handling all matter. A hexadecimal private-key representation may appear shorter than a long public-key string while still being based on a security parameter selected by the scheme. Neither a long-looking identifier nor a complicated format guarantees adequate security. Randomness is particularly important when generating secret keys: if the selection process is predictable, an attacker may be able to reproduce the private key despite the use of otherwise sound mathematics.

NIST FIPS 186-5, Digital Signature Standard, specifies signature techniques including RSA, ECDSA, and EdDSA. It does not mean that every network's particular implementation or curve has NIST approval merely because it belongs to one of those broad families. Standards apply to defined algorithms and configurations. Similarly, verifying a public key's mathematical validity may be only one part of securely interpreting an incoming message. Protocol software must also check the signature encoding, the authorized message, and relevant transaction rules.

Public keys, identities, and certificates

On the open internet, public-key infrastructure often uses digital certificates to bind a public key to a named subject through a certificate authority and a defined validation process. In many blockchain transactions, by contrast, public verification operates without a certificate naming a person. The protocol may only need to know whether a permitted key or spending condition authorized a message. An address that looks like a pseudonym is therefore not a digital certificate. A named exchange account may add identity verification through an entirely separate business process, but that information does not appear automatically in the cryptographic signature.

Everyday checks for nontechnical reviewers

• Ask which exact signature scheme and network a system uses; “blockchain cryptography” is not a sufficient answer.
• Distinguish a public key from a public address, a transaction identifier, and an account identifier.
• Treat a verified signature as a claim about a message and key, not as a standalone proof of legal identity.
• Require independent evidence when a policy depends on the signer's authority or organizational role.

In practice, implementations may expose only an address and transaction identifier, with a public key or signature hidden behind additional interface tabs. This is a presentation choice rather than evidence that signatures do not exist. Some smart-contract arrangements authorize actions under programmable conditions rather than a single ordinary key signature. The important foundation is to identify who or what can verify authorization and what conditions the underlying protocol actually checks. Details of storing private keys, seed phrases, recovery, and custody arrangements belong to the next module.

Exam focus: Define private and public keys and explain why public verification does not reveal the private key. Recognize ECDSA, Schnorr, and Ed25519 as named technical approaches, and distinguish cryptographic control of a key from proof of personal identity or lawful authority.