PGP Key Metadata: The Unintended OSINT Goldmine for Vendor Attribution

TLDR: Dark net vendors frequently leak their real-world identities by including identifiable metadata in their PGP public keys. By extracting email addresses and cross-referencing them with data breaches and social media, researchers can perform high-fidelity attribution on anonymous actors. This talk proves that even when vendors attempt to use encryption, poor operational security (OPSEC) during key generation often provides the exact pivot point needed to deanonymize them.

Most security researchers treat PGP keys as static blobs of data, useful only for verifying signatures or encrypting payloads. We often assume that if a target is using PGP, they have at least a baseline understanding of privacy. That assumption is a mistake. In the world of dark net marketplaces, PGP keys are not just security tools; they are often the most significant source of intelligence for anyone performing attribution.

The core issue is that PGP key generation is an interactive process that prompts the user for information. Many vendors, either out of laziness or a misunderstanding of how PGP works, fill these fields with real-world identifiers. They treat the "User ID" packet as a business card, inputting their actual email addresses, real names, or handles they use across the clear web. Once that key is uploaded to a marketplace, that metadata is baked into the public key forever.

Extracting the Signal from the Noise

Performing this kind of research at scale requires moving beyond manual inspection. You cannot realistically audit thousands of PGP keys by hand. The methodology demonstrated in this research relies on using GnuPG to parse the key packets and standard command-line utilities to filter for the data we care about.

When you have a collection of keys, the first step is to isolate the User ID packets. You can use the following command to list the packets and extract the relevant strings:

gpg --list-packets <key_file> | egrep "^:user ID packet"

This command strips away the cryptographic noise and leaves you with the identity information the vendor chose to associate with their key. Once you have these strings, you can use regex to identify patterns that look like email addresses. A simple Python snippet using re.findall can quickly parse a large file of extracted User IDs to find potential email domains:

import re
# Assuming 'user_ids' is a list of strings extracted from the keys
emails = [re.findall(r'[\w\.-]+@[\w\.-]+', uid) for uid in user_ids]

The real power comes when you pivot this data. An email address found in a PGP key is a high-value indicator. If that email appears in Have I Been Pwned, you are no longer looking at an anonymous vendor; you are looking at a person with a digital history. You can see which other services they registered for, what their username patterns are, and potentially even their real name or physical location if the breach data is comprehensive enough.

The Cost of Poor OPSEC

During the research, over 700 vendor profiles were analyzed across ten different dark net marketplaces. The findings were stark. While a majority of vendors did use unique keys for different personas, a significant portion—roughly 30%—reused the same PGP key across multiple accounts. Even worse, many vendors failed to follow the most basic OPSEC principle: leave the metadata fields blank.

One specific case study involved a vendor who used the same email address to register for an unemployment benefits portal during the COVID-19 pandemic as they did for their PGP key. When that portal suffered a data breach, the resulting leak provided a direct link between the vendor’s PGP key and their real-world identity, including their full name and physical address. This is a classic example of A07:2021 – Identification and Authentication Failures, where the failure to protect identity information leads to a complete compromise of the actor's anonymity.

Why This Matters for Pentesters

For those of us conducting red team engagements or OSINT-heavy assessments, this is a reminder that the "anonymous" threat actor is rarely as anonymous as they think. When you are tasked with identifying the operators behind a specific campaign, start with the artifacts they leave behind. If they are using PGP to communicate, that key is your first target.

Do not just look at the key's fingerprint. Look at the metadata. Look at the email addresses. Look at the creation dates. If you find an email address, run it through your standard OSINT stack. Check it against social media, check it against breach databases, and check it against domain registration records.

Defenders should take note: if you are managing internal PGP infrastructure, enforce a policy that requires the use of keys without identifying metadata. For developers and researchers, the lesson is simple. If you are going to use PGP, treat your metadata as if it were a clear-text password. If you put your real-world identity into a PGP key, you are essentially signing your own deanonymization report.

The next time you encounter a PGP key in the wild, don't just verify the signature. Parse the packets. You might find that the vendor has already handed you the keys to their real-world identity.