Tiny Rocket Blog
PGP + Discord = ??

Table of Contents
- TL;DR
- Introduction
  - Just Use Matrix?
  - Why PGP?
- Design Goals
- Methodology
- Implementation Notes
- Potential Problems
- Next Steps
- Appendix: Quick Usage

TL;DR
I built a prototype extension (PGPCord) that lets you send PGP-encrypted messages over Discord by encrypting payloads client-side before they're posted. It demonstrates a practical way to layer end‑to‑end encryption on top of an untrusted platform. There are important limitations and attack surfaces — this is proof of concept, not a battle-tested privacy product.

Introduction
When you want to send truly private messages, you end up choosing between convenience and security. Centralized chat platforms are convenient but they require you to trust the client/server stack. Traditional E2EE messaging (Matrix, Signal, etc.) reduces server trust, but often pushes complexity into key‑exchange and relies heavily on client and server implementations being correct.

Just Use Matrix?
Matrix is a great open protocol with first‑class E2EE in many clients, but:
- You still need to trust the client implementation (and, if you run your own server, the server implementation).
- Many people will not adopt a new platform, so you lose the network effect.
- Matrix E2EE can be brittle (key handling, device sync, and trust management introduce complexity).
So while Matrix is ideal in many contexts, it’s not a practical migration for everyone you talk to.

Why PGP?
PGP has a few pragmatic properties that make it useful as a compatibility layer:
- Keys are user‑generated and exportable. Public keys can be shared freely; private keys remain local.
- No server can decrypt messages if encryption is done correctly client‑side.
- People already know PGP and key distribution practices (web of trust, key servers, posting public key on websites).
PGP is not perfect UX, but for an add‑on that encrypts text before it hits Discord, it brings a clear separation of trust: Discord carries ciphertext only.

Design Goals
- Minimal change to user workflow: write a message in Discord as usual, but allow the extension to encrypt it before sending.
- Client-side private key storage: never upload or expose private keys to Discord or external services.
- Shareable public keys: let users publish their public key (profile, blog, keyserver) for others to use.
- Transparent UX: decrypt messages when they appear in the client UI if the recipient has the private key available locally.

Methodology
1. Key management:
   - Users generate a PGP keypair in the extension or import an existing one.
   - The extension stores the private key in the browser's secure storage (IndexedDB / WebCrypto-wrapped) and exposes the public key for sharing.
2. Encrypt before send:
   - When composing a message, the extension intercepts the send action, encrypts the plaintext using recipients' public keys, and posts the ciphertext instead.
   - Format the ciphertext in a detectable wrapper (PGP ASCII armored block, optionally with a small header to help the extension detect it later).
3. Detect and decrypt:
   - When the client receives messages (including messages from other users), the extension scans for armored blocks, attempts decryption with local private keys, and replaces the ciphertext inline with the decrypted text in the UI.
4. Fallback:
   - If a recipient lacks a public key in their local address book, fall back to the plaintext send (or warn).
   - Provide a way to send a "public key request" message to a user.

Implementation Notes
- Interception methods vary by platform and client:
  - Web client: content scripts can modify the compose box, listen for submit events, and change outgoing payloads.
  - Desktop clients: depends on extensibility (Electron clients might be patchable, native clients are harder).
- Cryptography:
  - Use a modern OpenPGP implementation (OpenPGP.js or similar).
  - Use reasonable defaults for key size and algorithms, but allow user control.
  - Protect private keys with a passphrase and, when possible, integrate with WebCrypto for key wrapping.
- UI:
  - Simple indicators for encrypted messages (lock icon, origin public key fingerprint).
  - Automatic decryption should be opt-in per user to avoid leaking metadata or surprising the user.

Potential Problems
- Interception before encryption: the extension must be able to intercept and encrypt messages before they are sent. If the platform or client modifies content after the extension runs (or the extension hooks into the wrong event), plaintext might leak.
- Metadata leakage: while the message body can be encrypted, metadata (recipient, timestamps, channel names) stays visible to the platform.
- Key discovery and authenticity: publishing a public key somewhere doesn't guarantee it's the right key for a given Discord user account — an attacker could publish a rogue key. You still need a way to verify key ownership (fingerprint verification, posting key on authoritative profile pages).
- Usability: key handling, passphrases, and import/export are UX pain points; users may make mistakes (e.g., losing private keys).
- Platform countermeasures: some clients may obfuscate or restrict script-based modification, breaking the interception approach.
- Legal and policy: automating encryption in messages might run afoul of platform policies or moderation tools that rely on plaintext scanning.

Next Steps
- Harden interception points and test across desktop and web clients.
- Add a simple key discovery flow (profile metadata, pastebin, or DNS TXT records pointing to a public key).
- Improve private key security by integrating browser-native key stores where available.
- Explore message formats that minimize accidental plaintext leaks (e.g., envelope with metadata encrypted) and robust detection heuristics.
- Perform threat modeling and consider consequences if keys are exfiltrated or if an attacker controls the extension update mechanism.

Appendix: Quick Usage (Prototype)
1. Install the extension in your browser.
2. Generate or import your PGP key within the extension and publish your public key where your contacts can find it.
3. When composing a Discord message, select the recipient or channel and use the extension's encrypt action — your text will be replaced with an armored PGP block before send.
4. When you receive an armored block, the extension will attempt to decrypt and render it inline.

Closing thoughts
This approach is a pragmatic way to add end‑to‑end confidentiality on top of an existing platform without requiring everyone to switch services. It doesn't eliminate all risks, and it's not a drop-in replacement for a secure messaging app, but it can be a useful bridge while preserving familiar workflows. The biggest practical problems are interception timing, key authenticity, and handling metadata — if you can accept those constraints, PGPCord-style tooling can meaningfully reduce exposure of message plaintext to untrusted servers.

If you want, I can:
- Produce the extension skeleton (OpenPGP.js + content script hooks for Discord web),
- Implement a robust key import/export UI,
- Or adapt the design into a small demo you can run locally.

(End of post)
