English   Français   Deutsch   中文   日本語

Home   Blog   Contact   Blogroll

Cryptographic Trust and OpenPGP Explained

2026-02-18T19:57:27+08:00

In this post I explain cryptographic trust, OpenPGP, how they work and why they matter.

Technical background: how mathematics defend security and privacy

If you do not care about the underlying mathematical principles of asymmetric cryptography and OpenPGP and only want to know how to use cryptographic trust wisely, you need to know these points:

If you only need practical guidance, you may skip the rest of this section.

Symmetric encryption uses the same key for encryption and decryption. It can be secure against brute-force attacks, but it has practical drawbacks. If Alice and Bob use symmetric encryption to exchange messages, they must first agree a shared key, which typically requires a separate secure channel (for example, meeting face to face). That is inconvenient, and the shared key must not leak—if Mallory obtains the key, confidentiality is lost.

Asymmetric cryptography addresses this. Asymmetric schemes use different keys for encryption and decryption—called the public key and the private key respectively. Public keys may be published on a personal website or on social media, because a public key cannot be used to derive the corresponding private key; the private key remains secret with its holder.

Carefully designed algorithms generate private/public key pairs so that data encrypted with a public key can be decrypted only by the corresponding private key. Examples include RSA and Elliptic Curve Cryptography (ECC).

RSA is a classical asymmetric algorithm and has the longest history. Understanding RSA helps build an intuition for asymmetric cryptography.

Briefly, RSA key generation works as follows. Alice randomly selects two distinct prime numbers p and q. She computes n = p * q and Φ(n) = (p - 1) * (q - 1), then chooses an integer e with 1 < e < Φ(n) that is coprime to Φ(n). She next computes the modular inverse of e modulo Φ(n) and sets it to d. Alice's public key is (n, e) and her private key is (n, d). To encrypt a message m, Bob computes c = (m ** e) % n and sends the ciphertext c to Alice; Alice recovers m with m = (c ** d) % n.

One may ask: given the public key (n, e), can we recover d? To compute d we need Φ(n), and to compute Φ(n) we must know p and q. Recovering p and q from n requires factorising n. For commonly used RSA key sizes (for example 4096 bits), n lies between 2**4095 and 2**4096; factorising such large n is computationally infeasible with current methods. This is the basis of RSA's security.

ECC and other asymmetric schemes use different hard problems, but they all share the same core idea: the scheme must make it computationally infeasible to derive private keys from public keys.

When we compute the modular inverse of e modulo Φ(n), we choose the smallest positive inverse, which is less than Φ(n). Suppose g = gcd(d, Φ(n)) > 1. Then (e * d + k * Φ(n)) / g would be an integer. But because e * d + k * Φ(n) = 1 for integers d and k, this would imply 1 / g is an integer, which is impossible unless g == 1. Therefore d is coprime with Φ(n). This symmetry means e and d have complementary mathematical properties; in theory one can swap their roles, and (n, d) and (n, e) form a mathematical pair. In practice, signature and encryption use these values in different, well-defined ways.

Concretely, signing in RSA is commonly performed by computing a signature s = m ** d % n, and verifying by checking m == s ** e % n. For practical end-to-end confidentiality plus authentication, a sender typically signs a message with their private key and then encrypts the signed data with the recipient's public key. The recipient decrypts with their private key and then verifies the sender's signature with the sender's public key.

What is cryptographic trust and why it matters

Worldwide surveillance and censorship affect communications everywhere. Beyond well-known high-risk jurisdictions, policies such as “chat control” proposals in some regions have raised concerns in Europe. Using free-software instant messengers that support end-to-end encryption—such as XMPP, Matrix and SimpleX—helps protect communications to some extent. Asymmetric cryptography enables pairs of contacts to establish secure channels without an existing secure tunnel: one key is used for encryption and the other for decryption, and only holders of the corresponding private key can reveal the encrypted content.

However, another problem remains: Alice and Bob may attempt to exchange public keys but be subject to a man-in-the-middle attack. Suppose Mallory intercepts both Alice's and Bob's public keys and instead sends her own public key to each of them. Alice will (mistakenly) treat Mallory's key as Bob's, and Bob will treat Mallory's key as Alice's. When Alice sends a signed and encrypted message intended for Bob, Mallory can decrypt it (using her private key), read or modify it, re-sign it with her private key and forward it to Bob. Bob will decrypt and verify the signature with Mallory's public key and (mistakenly) believe the message came from Alice. Mallory has thus broken both confidentiality and authenticity.

To prevent this, Alice must verify that the public key she received really belongs to Bob. This verification itself requires a trustworthy channel (for instance, meeting in person). The act of confirming that a public key belongs to a particular holder is what we mean by establishing cryptographic trust.

Once Alice trusts that a given key belongs to Bob, it is practically infeasible for Mallory to impersonate Bob without deriving Bob's private key from his public key.

The core principle of cryptographic trust: identity consistency verification

You can build extensive trust graphs between identities, but the core principle is simple: you establish cryptographic trust in an identity by verifying that this identity is consistent with another identity you already trust.

In cryptography, a public key corresponds to an identity. Remember: public key = identity (in the context of key-based trust).

Verification of identity consistency typically involves two steps:

For example, if Alice wants to verify that a public key belongs to Bob, she can meet Bob and ask for the key's fingerprint. Alice may also ask Bob to sign a short challenge (for example the text “I am Bob” or a random challenge generated by Alice). If the signature verifies with the public key, Alice establishes trust in that key.

Now consider another public key (key B) that Alice expects to belong to Bob, while Alice already trusts key A. Instead of meeting Bob again, Alice can verify the consistency between key B and key A by asking for mutual attestations:

If both signatures verify, key A and key B are linked and trust in key B follows from trust in key A.

Which identity to trust first?

Cryptographic trust establishment relies on an already trusted identity. For a new contact, the common approach is to trust the first identity you encounter; this is called ToFU (Trust On First Use), and that initially trusted identity is the initial identity.

For example, if Alice and Bob meet in person, Alice's initial trusted identity for Bob is the person she meets. If they meet in a Matrix community, the initial trusted identity may be Bob's Matrix account and its public key. If they meet on XMPP, Alice may trust the OMEMO fingerprint from Bob's first message.

This is a reasonable practical approach: when you meet someone you first encountered online, you typically verify their real-world identity using the same communication channel you used to meet them.

Common cryptographic trust practices

By verifying consistencies between identities, Alice builds a graph whose vertices are identities and whose edges are guaranteed consistencies. All vertices connected to Bob's initial identity form Bob's trusted identities.

Common strategies include:

  1. Unrestricted trust chain / network. Any trusted identity may be used to establish trust in another identity by verifying consistency. The network grows freely.
    Pros: Convenient; less likely to lose connectivity if some identities are lost.
    Cons: Less robust against impersonation—long trust chains can form, and compromise of one identity can affect many others.

  2. Initial-identity centric. Only the initial identity may be used to establish trust in a previously untrusted identity.
    Pros: Robust if the initial identity is robust; trust chains are all of length one.
    Cons: If the initial identity is weak or compromised, trust cannot be built reliably; there is a single point of failure.

  3. Unique cryptographic identity centric. The initial identity first establishes trust in a unique cryptographic identity (typically a key pair), and only that cryptographic identity is thereafter used to vouch for other identities. This is my preferred strategy; I use OpenPGP for this purpose.
    Pros: Good balance between central robustness and short trust chains.
    Cons: Still a single point of failure: compromise of the central key compromises downstream trust.

A common identity-verification approach: challenge–response

If Alice already trusts one of Bob's public keys but wants to verify that the person at the other end holds the corresponding private key, use a challenge–response:

  1. Alice generates a random string (the challenge).
  2. Alice sends the challenge to Bob; Bob signs it with his private key.
  3. Bob returns the signature; Alice verifies it using the public key.

The challenge need not remain secret after generation, but it should be unpredictable and unique. A valid signature proves the responder holds the private key.

Very important: do not compromise your private key

The security of cryptographic trust depends entirely on the secrecy of private keys. Compromising a private key undermines trust.

Therefore, do not compromise your private key. Once your private key is exposed, others' trust in you is no longer valid.

For OpenPGP users in particular: KEEP YOUR OPENPGP PRIVATE KEY TOP SECRET. Storing the private key on a hardware token (for example Nitrokey, CanoKey or a YubiKey) is good practice. If that is not possible, at least store your private key on a device that runs 100% free software.

OpenPGP and free-software implementations

OpenPGP is a standard rather than a single piece of software. It defines a format that aggregates and organises key material so it can be used for encryption, signing and authentication. OpenPGP supports RSA, ECC and other algorithms.

Using GnuPG as an example:

  1. Key generation: run gpg --full-generate-key and follow the prompts.
  2. Encryption: run gpg --encrypt. You may send the content to encrypt to standard input (for a file: cat <filename> | gpg --encrypt). The encrypted output is sent to standard output; by default it is binary, so redirect it to a file. To produce ASCII-armoured output, use gpg --encrypt --armor.
  3. Clear-text signing: run gpg --clear-sign and enter the text on standard input; press Ctrl+D when finished. The signed text is written to standard output.
  4. Decryption and verification: run gpg --decrypt and supply the encrypted or signed data on standard input. Decrypted data is written to standard output; verification results are reported on standard error.

On GNU/Linux and *BSD, and also on Microsoft Windows and macOS, the most widely used implementation is GnuPG, and a graphical front end is Kleopatra. On Android, OpenKeychain is a popular choice.

Detailed guides are beyond this article's scope; consult the relevant documentation. The FSF's Email Self-Defense Guide is a good starting point. If you want to dive deeper, see resources such as the GnuPG manual, FSFE's OpenPGP guide and KDE's OpenPGP for Beginners.

How to use OpenPGP to encrypt e-mail

Free-software e-mail clients such as Thunderbird have built-in OpenPGP support. You can use OpenPGP to encrypt, decrypt and verify signatures seamlessly. Browser extensions such as Mailvelope can add OpenPGP support to webmail providers.

Consult documentation and other guides to learn the exact steps for your client.

How to use OpenPGP to establish cryptographic trust

Using OpenPGP to establish cryptographic trust is straightforward:

  1. Request a person's OpenPGP public key.
  2. Verify the consistency between the key and the person's initial identity; this establishes trust in the key.
  3. In future, when verifying other identities for that person, check consistency between the OpenPGP key and the identity you wish to trust.

Final words: embrace free software, and use it wisely

Thanks to the free-software community, many robust tools are available. By learning how to use them we gain the power to defend security, privacy and digital rights, and to protect ourselves from surveillance, censorship and other threats.

Tildeverse Banner Exchange