↓ Skip to main content
Le Site de François
  1. Index/

OpenPGP / GPG

Cryptography Security Signing Pki Supply-Chain Email

OpenPGP is an open standard for encryption and digital signatures of arbitrary data, defined in RFC 4880 (2007) and substantially revised in RFC 9580 (2024, adding Ed25519, X25519, and modern AEAD encryption). GnuPG (GPG) is the dominant open-source implementation, maintained by Werner Koch and the GnuPG project, and the tool most users interact with. OpenPGP predates the PKI/CA model and takes a fundamentally different approach to trust: rather than a hierarchy of certificate authorities that users must trust transitively, OpenPGP uses a Web of Trust in which individual users sign each other’s public keys, and trust is established through chains of personal endorsements. In the Web of Trust model, Alice trusts Bob’s key because she verified it in person and signed it; Carol trusts Bob’s key because Alice (whom Carol trusts) signed it. This decentralised, peer-to-peer trust model made sense for email encryption between individuals who could meet at key-signing parties, but does not scale to automated infrastructure verification, which is why OpenPGP’s role in modern infrastructure is primarily supply chain signing — package repositories, Git commits, and release artifacts — rather than interactive authentication.

An OpenPGP key is a certificate that bundles a primary key (used for certification — signing other keys — and optionally for signing data) with one or more subkeys (for encryption, signing, and authentication), each with its own algorithm and validity period, all bound together by self-signatures from the primary key. The primary key’s fingerprint (SHA-1 historically, SHA-256 in RFC 9580) is the durable identity of the key, and is what users publish on keyservers (SKS, keys.openpgp.org), in DNS DANE records, or in their GitHub profiles. Key management in GnuPG is handled by the gpg CLI and, for smartcard/hardware token integration, by gpg-agent and the scdaemon: OpenPGP keys can be generated on and stored in hardware tokens (YubiKey with OpenPGP applet, Nitrokey) so that the private key never leaves the hardware, providing FIDO2-like physical presence requirements for signing operations. A signed OpenPGP packet (a --clearsign, --detach-sig, or --sign output) contains the data, the signature, and the signer’s key fingerprint; a verifier who has the signer’s public key can verify the signature without any CA or network call. Encryption in OpenPGP uses a hybrid scheme: a random session key is encrypted under each recipient’s public encryption subkey using RSA or X25519 (ECDH, per RFC 9580), and the data is encrypted with AES-256 using that session key.

The primary infrastructure uses of OpenPGP in this glossary’s context are three. Linux package signing: RPM (RHEL, Fedora) and DEB (Debian, Ubuntu) packages are signed with the distribution’s OpenPGP key; dnf and apt verify these signatures against the distribution’s public key (distributed in /etc/pki/rpm-gpg/ or via apt-key) before installing any package — GPG is the trust anchor for the entire package supply chain on Linux. Git signing: git commit --gpg-sign and git tag --sign embed OpenPGP or SSH signatures in Git objects; GitHub, GitLab, and Forgejo display verified badges for commits signed with a key registered to the author’s account, and tools like gitsign (from Sigstore) use ephemeral OIDC-bound certificates rather than long-lived OpenPGP keys for keyless Git signing. Email encryption: S/MIME and OpenPGP are the two competing email encryption standards; OpenPGP via Thunderbird/Enigmail or native Thunderbird 78+ support provides end-to-end encrypted email without a CA, though the Web of Trust’s usability barriers have limited adoption. The PQC transition is partially addressed in RFC 9580: the standard adds support for ML-KEM-768 and ML-DSA-65 (alongside the existing Ed25519/X25519 support) as OpenPGP algorithm identifiers, and GnuPG 2.5.x development branch implements these. The transition path is adding a PQC encryption subkey and a PQC signing subkey to existing OpenPGP keys — compatible with existing key management infrastructure — while retaining the classical subkeys for interoperability with verifiers that have not yet updated.

Related

Sigstore

Supply-Chain Security Signing Oci Pki Oidc Cncf
Sigstore is an OpenSSF project, initiated by Google, Red Hat, and Purdue University, that provides a free public-good infrastructure for cryptographically signing software artifacts — container images, binaries, SBOMs, attestations — without the operational burden of managing long-lived private keys. Its founding insight is that the two hardest problems in code signing are key management (generating, protecting, distributing, rotating, and revoking signing keys across thousands of developers and CI pipelines) and signature discoverability (how does a verifier find and trust the correct public key for an artifact it has never seen before). Sigstore solves both by eliminating long-lived keys entirely: every signing operation generates a fresh ephemeral key pair, uses it once, discards the private key, and records the event in a public transparency log — replacing “do you trust this key?” with “do you trust this identity at this moment in time?”.

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.

HSM (Hardware Security Module)

Security Hardware Cryptography Key-Management Pki Fips
A Hardware Security Module (HSM) is a purpose-built, tamper-resistant hardware device that holds cryptographic keys and performs cryptographic operations — signing, encryption, decryption, random number generation — entirely within its own protected boundary. The defining property is that private keys generated inside an HSM never exist in plaintext outside it: operations that need the key are sent into the HSM and the result is returned, but the key material itself cannot be extracted. This property is enforced both logically (the firmware refuses export in plaintext) and physically (the device detects and responds to tampering by erasing key material before an attacker can read it). HSMs come in several physical forms: network-attached appliances (rack-mounted devices accessed over the network by many clients), PCIe cards (embedded in a server), and compact USB devices for lower-throughput use cases like protecting CA root keys offline.