Public Key

In short: The English term for the public key of an asymmetric key pair.

In more detail: In practice (code, CLI tools, filenames like id_rsa.pub), the English term “public key” is used almost throughout, even in German-language documentation. Generated together with the private key and can, for example, be stored on GitHub to authenticate via SSH without a password.

In Depth

A concrete everyday example: passwordless login via SSH works entirely through public-key cryptography, without a password ever being transmitted over the network:

# One-time: generate a key pair
ssh-keygen -t ed25519
 
# Copy the public key to the target server
ssh-copy-id user@server.com
 
# After that: login works without entering a password
ssh user@server.com

During a login attempt, a so-called “challenge-response” procedure runs in the background: the server sends a random string (the “challenge”) to the client, the client signs it with its private key and sends the signature back, and the server checks the signature with the stored public key. If it matches, this proves beyond doubt that the client possesses the matching private key — without it ever having to leave its own device.

The same basic idea appears on GitHub/GitLab: your own public key is stored in your profile, and afterwards you can clone/push repositories via Git over SSH without entering credentials for every action — convenient, but also a reason why a stolen private SSH key potentially gives access to ALL repositories for which the matching public key is stored.

Public keys beyond the SSH context

The principle isn’t limited to SSH: in TLS certificates, every certificate contains the server’s public key, which the browser uses to securely negotiate the session key for the actual encrypted communication. With digital signatures (e.g. signed software updates), the publisher’s public key is used to verify that a signature really comes from the stated sender and that the signed data hasn’t been altered since the signature was made. With cryptocurrencies like Bitcoin, your own “wallet address” is derived directly from a public key — anyone wanting to receive a transfer shares their public key (or the address derived from it), never the private one.

Key formats in practice

In practice you usually encounter the public key in one of several text formats: the OpenSSH format (a single line starting with ssh-rsa or ssh-ed25519) is typically stored in ~/.ssh/authorized_keys or platform profiles like GitHub. The PEM format (base64-encoded, framed by -----BEGIN PUBLIC KEY-----) is the common standard for TLS certificates and many other cryptographic applications. Both ultimately encode the same mathematical key data, just in a different text representation for different tools.

Distribution and trust

A public key is by definition uncritical if it falls into the wrong hands — the real security problem isn’t secrecy, but authenticity: how does the recipient know that a public key really belongs to the claimed person/domain, and wasn’t substituted by an attacker (“man in the middle”)? With TLS, certificate authorities solve this by confirming the binding between domain and key via a certificate. With SSH, you blindly trust on the very first connection (“trust on first use”) and remember the fingerprint (hash of the public key) for future connections — if this fingerprint later changes unexpectedly, the SSH client warns, because that can mean either a server reinstall or an attack attempt. With PGP/GPG there’s the “web of trust” for this: users mutually sign the public keys of people they know, to build a decentralised trust network entirely without a central certificate authority.

See also: Private key, Asymmetric encryption