Two keys that belong together
Symmetric encryption uses one secret key: whoever has it can both encrypt and decrypt. That works only if both sides already share the secret, which is the problem you were trying to solve.
Public-key cryptography, also called asymmetric cryptography, splits the job across two related keys. NIST’s key management guidance defines it as an algorithm that uses a public key and a private key, with the property that determining the private key from the public key is computationally infeasible. That property is what makes the arrangement safe:
- The private key is uniquely associated with its owner and is never made public.
- The public key is associated with the same owner and may be published anywhere: in a directory, in a QR code, or inside the message itself.
Key pairs are used for two main jobs: signing and key agreement.
Signatures prove who wrote something
A digital signature is computed from a message and a private key. Anyone with the matching public key can check it. According to NIST’s Digital Signature Standard, FIPS 186-5, signatures detect unauthorised changes to data and authenticate the identity of the signer. Change one bit of the message and the signature no longer verifies. Only the private key could have produced a valid one.
Ed25519 is a common signature scheme, specified in RFC 8032 and included in FIPS 186-5 as part of EdDSA. RFC 8032 lists its practical advantages: small public keys of 32 bytes and signatures of 64 bytes, no need for a fresh random number for each signature, and more resilience to side-channel attacks. You can read more in the Ed25519 glossary entry.
Signatures do not hide anything. A signed message is still readable by anyone who sees it. Signing gives integrity and authenticity; keeping content secret needs encryption.
Key agreement creates a shared secret
To encrypt, two devices usually want a shared symmetric key, because symmetric encryption is what protects message content. Key agreement lets them create one over a channel anyone can watch.
RFC 7748 describes how this works with X25519. Each side generates 32 random bytes as a private key and sends the other its public value. Each then combines its own private key with the other’s public value, and both arrive at the same shared secret. An observer sees both public values but cannot compute the secret. The two sides then run the secret through a key-derivation function to produce the symmetric keys they will actually use.
NIST describes key agreement as a procedure in which the resulting key is a function of information contributed by both participants, so neither can choose it alone. End-to-end encryption is built on this step.
One key, one job
NIST SP 800-57 says that, in general, a single key should be used for only one purpose, such as encryption or digital signatures. Using the same key for two processes can weaken both, and limiting each key’s use limits the damage if it is compromised.
So a device that does both typically holds separate pairs: an Ed25519 pair for signing and X25519 pairs for agreeing keys. MLS, the group messaging standard, requires the encryption key and the signature key in each member’s entry to be distinct.
Knowing whose key it is
The mathematics guarantees that a signature came from the holder of a private key. It cannot tell you who that holder is. If an attacker can hand you their public key labelled with someone else’s name, every later check succeeds against the wrong person.
There are three common answers:
- Certificates. A trusted party signs a statement binding a public key to a name. NIST calls this a public-key certificate, and the system that issues and revokes them a public key infrastructure.
- Direct comparison. People compare a short fingerprint of the key, or scan each other’s QR code, in person or over a channel they already trust.
- Trust on first use. Accept the first key you see for a contact and warn loudly if it ever changes.
Some systems make the key itself the identity. In Offline Protocol’s mesh SDK, each device’s address is derived from its Ed25519 public key, so a message signed by that key is bound to that address. The application still decides which addresses to trust.
Keeping private keys private
NIST requires confidentiality protection for private keys and integrity protection for all key information. In practice that means generating keys on the device, storing them in the platform’s secure storage where possible, never sending them over the network, and planning what happens when a device is lost.
RFC 8032 notes that a sufficiently large quantum computer would be able to break both Ed25519 and Ed448.