EMZETT.Public Key (Öffentlicher Schlüssel)
Image: Stern, Public domain, Wikimedia Commons
_Schema.svg){kind=link}
In short: The part of an asymmetric key pair that can be distributed freely and is used to encrypt messages or check signatures. Synonym: public key.
In more detail: Unlike with symmetric encryption, the public key doesn’t have to be kept secret — on the contrary, it’s deliberately published (e.g. in a certificate). What was encrypted with the public key can only be decrypted with the corresponding private key, and conversely a signature created with the private key can be checked with the public key.
In Depth
A public key in OpenSSH format looks like this (from the file id_ed25519.pub):
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGx8... user@computer
This line can be shared anywhere without hesitation — e.g. entered in a GitHub profile or copied to a server. On its own it does NOT grant access to anything — an attacker who only knows the public key can neither establish a connection with it nor read encrypted messages, but at most encrypt new messages TO the owner of the matching private key or verify their signatures.
Public keys typically become visible in one of two contexts: embedded in a certificate (which additionally supplies identity and a trustworthy signature, e.g. in TLS) or “raw”, without any further attestation, as with SSH keys — there, on the first connection, you usually rely on “trust on first use” (the fingerprint is stored on first contact and compared on every further connection, instead of checking a complete certificate chain).
The distribution problem that public keys solve
Before asymmetric cryptography was invented (see Asymmetric encryption), two parties who wanted to communicate in encrypted form first had to exchange a shared secret key over an already secure path — a chicken-and-egg problem when no secure channel exists yet. The public key solves this problem elegantly, because by definition it does NOT have to be secret: you can transmit it over a completely insecure, publicly visible channel (email, website, even read out aloud on the phone) without an eavesdropper being able to do anything with it other than send encrypted messages TO the rightful recipient themselves.
Trust on first use in detail
The “trust on first use” principle (TOFU), which SSH uses by default, has a known weakness: on the very first connection to a server, the client has no independent way of checking whether the public key presented really comes from the genuine server or was slipped in by an attacker (man in the middle on the first connection). SSH clients therefore show a warning with the key’s fingerprint on the first connection and explicitly ask for confirmation — security-conscious administrators compare this fingerprint via an independent channel (e.g. internal documentation) instead of accepting it blindly. On ALL further connections, SSH automatically checks whether the key has changed since the first contact — a sudden change triggers a clear warning, because this can indicate either a legitimate rebuild of the server or an active attack.
Key lengths and algorithms compared
Depending on the algorithm used, the typical size of a public key differs considerably: a 4096-bit RSA key is much longer and slower to process than a modern Ed25519 key (elliptic curves, a fixed 256 bits), which is considerably more compact at comparable security — one reason why ssh-keygen -t ed25519 is recommended today over the older RSA standard, both for faster connection setup and for shorter, easier-to-handle key files.
See also: Public key, Private key, Asymmetric encryption