Signal Encryption Stops at the Endpoint

Key Takeaways

Does Signal’s end-to-end encryption stop law enforcement or OSINT collectors from reading messages and mapping groups?

No. End-to-end encryption protects messages in transit between devices. It does nothing once an investigator has the Signal Desktop endpoint—or its on-disk database and keychain secret. Tools such as sigtop export that local store. One user-level export can place a person in 100-plus groups at once; one group export hands over every member’s stable UUIDv4 service ID. Messages, media and cross-group membership, not cryptanalysis, are the collection surface.

Signal sells privacy on the wire. The product does what it claims: messages between devices are end-to-end encrypted, so Signal’s servers cannot read them. That fact is not in dispute. The collection problem for investigators and OSINT analysts sits one layer down.

The local endpoint—the installed Signal Desktop app, its encrypted database, and the operating-system keychain secret that unlocks it—holds plaintext after decryption. An open-source tool named sigtop, written by Tim van der Molen, reads that store and writes messages, attachments, avatars and related data to disk. No cryptanalysis. No server compromise. Endpoint access.

That distinction is the spine of this piece. The payoff is larger than a chat dump. A structured user-level export can list every group an account belongs to—causes, workplaces, locations, hobbies, affiliations—often numbering in the dozens or 100-plus groups at once. A structured group-level export returns every member’s durable UUIDv4 service ID in one shot. And the messages and media themselves come with the export. The collection surface is the content, the media and the membership, not a broken protocol.

What Does sigtop Actually Export?

sigtop is a command-line utility. Its online manual is the authoritative list of shipped commands. The README’s two example commands are the everyday path:

`` sigtop export-messages messages sigtop export-attachments attachments ``

The man page documents a fuller set. export-messages writes per-conversation files as plain text, short text or JSON pulled from the desktop database. export-attachments writes media into per-conversation directories, with optional incremental runs and time filters. export-avatars pulls conversation avatars. export-database decrypts and dumps the SQLCipher store as a regular SQLite file. export-key exports the encryption key needed to unlock that database—or, with a flag, the database key itself. query-database runs read-only SQL against the live store. Conversation selectors accept a display name, a phone number, a service ID (a UUID) or a group ID.

sigtop must see Signal Desktop’s data directory. Defaults are %AppData%\Signal on Windows, $HOME/Library/Application Support/Signal on macOS, and $XDG_CONFIG_HOME/Signal or ~/.config/Signal on Unix, with Snap and Flatpak paths as fallbacks. A -d flag points elsewhere; -B targets Signal Desktop Beta. None of those paths is Signal’s cloud. The tool is local.

That is the operational fact investigators need. Physical access, a consented image, a corporate endpoint already under management, or a forensic extraction that includes the keychain material is enough. Remote compromise of Signal’s servers is not required and is not what sigtop does.

What Does an Endpoint Export Actually Contain?

sigtop’s commands are the unlock and the dump. The data model that falls out of a Signal Desktop endpoint collection—readable once the local database is unlocked—is richer than a message transcript. Described abstractly, with synthetic placeholders only, a user-level export and a group-level export look like this.

A user-level export typically exposes:

• The account’s service ID, a UUIDv4 Account Identifier (ACI), plus the legacy phone number when present—for example, a dummy value such as aaaaaaaa-bbbb-4ccc-8ddd-eeeeeeeeeeee, never a live identifier.
• Current and historically observed profile names, which support alias tracking as a person renames themselves.
• An “about” profile blurb when set.
• A timestamped history of past avatars, each downloadable as an image—fuel for avatar reuse checks and face or reverse-image matching over time.
• A complete group-membership list: for each group, a name, description, member count and the account’s role (for example, member or admin).

A group-level export typically exposes:

• The group’s master key, invite-link password and derived secret params, from which a collector can reconstruct the current invite link while that link remains valid.
• A retention or disappearing-messages period when configured.
• Group-avatar history.
• A full member roster: every member’s UUIDv4 service ID, display name, profile name, role and avatar pointer—all at once.

The investigative point is structural. Observing a single group hands you every member’s stable UUID, name fields and avatar pointer in one pass—the raw material for cross-group correlation. Observing a single well-connected user hands you that person’s entire group landscape. Neither step requires reading message bodies. (Field names here describe the endpoint-derived model investigators work with after a local unlock; they are not a claim that every field is its own sigtop subcommand.)

Why Is Cross-Group Membership the Headline?

Membership alone can draw a useful picture. Cross-group membership is the headline capability. It is not the only one.

A single user-level export can place one person in dozens to 100-plus groups simultaneously. That list alone—advocacy causes, city or regional chats, employer or campus communities, hobby groups, mutual-aid circles, diaspora networks—reconstructs a detailed interest and social graph with zero message content. Repeated exports turn the list into a time series: which groups appeared, which disappeared, which roles changed.

Flip the lens. A single group-level export returns the full roster of UUIDv4 service IDs. Join several such rosters and the same synthetic member, say “User A” with service ID aaaaaaaa-bbbb-4ccc-8ddd-eeeeeeeeeeee, shows up in “Example Group,” “Example City Mutual Aid,” and “Example Alumni Chat.” Co-membership edges accumulate. The graph grows from observed rolls, not from ciphertext.

That is why endpoint collection and sustained group observation sit together. One desktop unlock can warehouse a user’s whole membership map. One group unlock can warehouse everyone else’s durable IDs. Correlation does the rest.

Messages and Media Are a Collection Surface Too

The same unlock that yields the group list yields the conversations. export-messages writes the text; export-attachments writes the photos, videos, voice notes and documents. That content is a collection surface in its own right, and users fill it themselves:

• Location. People name the city, the venue, the meeting point and the commute. Photos show landmarks and license plates even when the file carries no coordinates.
• Intent. Plans, dates, times and logistics are written out in plain language once the message is decrypted on the device.
• Links. ProtonMail Drive and Google Drive folders, other signal.group invites, social profiles and payment pages lead off the platform to accounts that carry their own identifiers.
• Exploitable media. EXIF metadata, the camera, time and GPS fields a phone writes into a photo, is the classic example, and the logic runs in two steps. First, Signal strips EXIF from photos sent through the app by default, a policy a Signal developer restated on its issue tracker. Second, a common pattern sidesteps that safeguard entirely: members paste links in chat to photos and files hosted elsewhere, such as a Google Drive or other cloud folder. Signal never processes those linked originals, so they keep their metadata, including GPS coordinates, device make and model, and capture timestamps. The link in the Signal message is the pivot; the hosted original carries the metadata, and with it further attribution and geolocation. Documents and other non-image attachments can carry author names, software versions and edit histories of their own. And a photo needs no metadata at all to give away a place: street signs, storefronts and skylines do that in the visible frame.

None of it requires defeating E2EE. The plaintext and the files sit on the endpoint after Signal has done its job.

Why Isn’t End-to-End Encryption Endpoint Security?

End-to-end encryption, or E2EE, encrypts content so that only the communicating endpoints can read it. Signal’s protocol does that well. The servers that relay ciphertext do not hold the message keys in a form that lets the company read chats.

E2EE says nothing about the endpoint after decryption. The desktop client stores a local database. The operating system’s credential store—Keychain on macOS, Credential Manager or DPAPI-backed secrets on Windows, libsecret on many Linux desktops—holds material sigtop can export with export-key. Once that material and the data directory are available, the messages and the membership metadata are available. Encryption protected the path between phones. It did not protect the laptop sitting on the desk.

This is not a novel critique of Signal. It is the standard trust model for any E2EE messenger. The device is the trust boundary. Treat a seized, imaged or administered Signal Desktop install as a collection surface, not as a cryptographic puzzle.

How Do Investigators Collect Without Cryptanalysis?

Law-enforcement and intelligence framing for Signal is observation, not cryptanalysis. You do not “break” the protocol. You stand where a participant already stands.

Inside a group, an observer sees what every member sees: messages, attachments, reaction patterns, and the links people paste. Shared ProtonMail Drive URLs, Google Drive folders, new signal.group invite links, and cross-referenced handles are all in the clear to anyone already in the chat. Membership itself is signal. Who was added, who left, who posts, and which outside identifiers appear in the scrollback are analytic facts before anyone opens an attachment.

That is why endpoint export and group observation sit together. sigtop and equivalent local reads turn one desktop into a structured archive. Group access turns many accounts into a living graph. Neither step requires defeating Signal’s cryptography.

Why Can’t You Brute-Force Signal Groups?

Signal’s modern groups are built around a group master key. In Signal’s group cryptography, that master key is a random thirty-two-byte value. Invite links of the form https://signal.group/#… encode that master key (plus an invite-link password) so a recipient can join. Signal’s own support page describes turning the link on and sharing it.

Thirty-two bytes of randomness is a two-hundred-fifty-six-bit keyspace. Guessing a group identifier by brute force is not a realistic collection method. The practical paths are fewer and more human:

1. Be added to the group, or operate an account that already is.
2. Receive the invite link through another channel.
3. Harvest invite links that participants post in public or semi-public venues—Reddit threads, Facebook and Instagram posts and stories, Telegram channels, paste sites, and the usual OSINT surfaces where people advertise “DM for the Signal link.”

Those links are ephemeral and revocable. Signal lets admins reset a group link (invalidating the old URL and issuing a new one) or turn the group link off entirely. Signal’s own product writing on group links makes the same point: you can turn the link off or reset it at any time. A scraped link found on Reddit last month may already be dead. That is why open-web link scraping is time-sensitive, and why sustained direct group observation—being inside, or holding a fresh endpoint-derived membership view—matters more than a one-time link grab.

Open-web harvesting remains the discovery method that scales for finding groups. Cryptography and revocability together force collectors onto that path and then onto continued observation.

What Identifiers Persist on Signal?

Signal’s durable user identifier is the service ID: the Account Identifier, or ACI, stored as a standard UUIDv4. It is a common protocol identifier, not a Signal-only curiosity. Phone numbers remain the legacy identifier used at registration and still visible in some contact contexts. Sigtop’s man page states the operational consequence plainly: “A service ID is a UUID that uniquely identifies a Signal user,” and conversation selectors of the form :id match on that service ID or on a group ID.

Almost everything else a person shows is ephemeral. Group invite links can be reset or turned off. Optional usernames are user-chosen, changeable or droppable at any time, and the username or discovery link rotates with them—a transient handle, not a stable ID. Signal’s own product writing emphasizes that a username can be altered or deleted and is not a stable public directory entry. Display names change. Avatars rotate. None of those presentation layers is the join key.

The UUIDv4 service ID is the one durable anchor. It persists through invite-link resets, username drops, nickname edits and avatar swaps. Membership lists and local databases key on it. An observer who correlates on the ACI can follow one person as presentation shifts; an observer who keys only on a username, a display name or a scraped signal.group link cannot.

Phone numbers that remain on an account continue to anchor older contact graphs. They are not permanent labels. Across roughly 700,000 accounts OctoProbe observed, only about 1.5 percent of registered phone numbers remained active after signup. The rest had churned or gone quiet. Treat number-based hits as leads to verify against the UUIDv4 and other corroboration, not as durable names for a person.

What Do Membership Snapshots Reveal Over Time?

With access to enough groups—through participated accounts, exported desktops, or collected invite links—repeated membership snapshots show which UUIDv4 ACIs appear together across the ecosystem. Appearances, disappearances and co-membership over weeks and months sketch a social graph built from observed rolls, not from reading every chat.

That graph is metadata in the investigative sense: who associates with whom, in which named communities, across which time windows. It is weaker than a full message export and often sufficient to prioritize targets, corroborate other reporting, or decide where a warrant or a further endpoint collection would matter. Large-group access multiplies the effect. One busy community’s member list is a roster. Many overlapping lists, joined on service ID, are a map—and a user export that already lists 100-plus groups is a map in a single file.

How Do Users Actually Get Unmasked?

Signal can separate a person from a phone number more than it used to. It cannot separate a person from habits. The classic OSINT de-anonymization chain still applies, viewed here from the defensive side:

• Username and handle reuse across Signal, Telegram, Reddit, X, GitHub and email local parts.
• Real-name reuse in profile fields, group nicknames and linked payment or crowdfunding pages.
• Avatar reuse, including the same crop or face appearing on other platforms where face matching or reverse-image search works—made sharper when an endpoint export includes a timestamped avatar history.
• Location talk in chat—“I’m at…,” flight complaints, local slang, venue check-ins pasted as links.
• Cross-posted invite links and cloud folders that carry account names, shared-drive permissions or tracker parameters.

None of that requires defeating E2EE. It requires correlating what participants voluntarily expose, then joining those traces to the stable UUIDv4. From a privacy perspective, the weak layer is continuity of identity across services, not Signal’s wire protocol.

Can a Signal Call Expose a Location?

Voice and video add a separate metadata path. Signal can relay call media through its TURN servers so that participants do not see each other’s IP addresses. It can also negotiate a peer-to-peer path.

Signal’s own 2017 product post on video calling leaving beta stated the default policy: the app attempts a peer-to-peer connection when the user is placing the call or when the incoming caller is in the user’s contacts; calls from people not in the address book are relayed. A setting—Always relay calls—forces relay for direct calls when enabled. Signal staff have since confirmed on the public issue tracker that the setting defaults to off, and that it applies to one-to-one calls; group calls are not peer-to-peer.

When a one-to-one call does go peer-to-peer, each side can observe the other’s IP address from the media path. An IP address is not a street address, but it is often enough for a coarse geolocation—city or metro—via standard IP intelligence. That is the classic STUN/TURN versus P2P tradeoff. Relay is available and recommended for wary users; it is not forced on for contact calls unless Always relay calls is turned on.

What Could Tooling Add Next?

The following are proposed analytical extensions, not features sigtop ships today. They are framed so engineers and oversight readers can see where endpoint-adjacent tooling naturally grows beyond today’s public commands and the endpoint-derived data model above:

• Avatar retrieval probes. A forced key-exchange or profile fetch against a UUIDv4 ACI to test whether an avatar is retrievable and to decrypt or download it when the protocol allows—useful for the avatar-reuse de-anonymization step above.
• Broader enumeration and bulk export. Structured sweeps of conversations, membership metadata, message bodies and media at a scale aimed at warehouse-and-query workflows rather than one-off directory dumps.

Mark those clearly as forward-looking. Today’s public sigtop surface is the man page: messages, attachments, avatars, database, key and read-only SQL. The user- and group-level field inventory described earlier is the shape of data available from a local unlock, not a second product claim. Overstating either helps no one.

What Should Defenders and Oversight Take From This?

For users who chose Signal for the cryptography: keep it—and harden the endpoint. Full-disk encryption, strong device passcodes, Screen Lock, disappearing messages where appropriate, care with group invite links, and Always relay calls when IP exposure matters are the controls that match the threat model this article describes. Do not paste signal.group links into public posts if the membership list is sensitive—and remember that resetting the link does not remove people who already joined. Do not reuse avatars and handles you use under a real name. Assume that anyone who obtains your desktop endpoint obtains your group list.

For investigators and oversight: document the legal theory for endpoint access, group undercover participation and invite-link collection the same way you would for any other messenger. The technical story is straightforward. The policy story—consent, warrant, covert online identity, minimization—is where the work is.

Editor’s note: This is a methodology explainer for defensive awareness and lawful collection analysis. It is not a how-to for targeting a private person. Capabilities attributed to sigtop track its public README and man page. The user- and group-level export field inventory describes the endpoint-derived data model in the abstract, with synthetic placeholders only. Proposed tooling extensions are labeled as such.

FAQ

What is sigtop? sigtop is an open-source utility by Tim van der Molen that exports messages, attachments, avatars and other data from a local Signal Desktop install. Its man page documents export-messages, export-attachments, export-avatars, export-database, export-key and query-database. It needs the desktop data directory and unlocking key material, not Signal’s servers.

Does end-to-end encryption protect a seized phone or laptop? No. E2EE protects content in transit between endpoints. Once an investigator has the device or the desktop database and its key, local plaintext and membership metadata are available. Signal’s design treats the device as the trust boundary.

Why is cross-group membership so powerful? A single user-level endpoint export can list every group that account belongs to—often dozens or 100-plus—with names, descriptions, sizes and roles. That list alone reconstructs interests and affiliations with no message content. A group-level export returns every member’s UUIDv4 service ID, names and avatar pointer in one shot, which is the raw material for correlating the same person across many groups.

Can you brute-force Signal group membership? Not in practice. Invite links carry a random thirty-two-byte group master key. Collection means group access or harvesting invite links posted in the open. Those links are revocable—admins can reset or disable them—so a scraped link is time-sensitive and sustained observation matters more than a one-time grab.

What is a Signal service ID or ACI? The service ID is the Account Identifier, a standard UUIDv4 that uniquely identifies a Signal user. Group invite links, optional usernames and username/discovery links are ephemeral; display names and avatars change. The UUIDv4 persists through all of them, so it is the durable anchor an observer correlates on. Phone numbers are the legacy identifier.

Does Signal hide your IP address on calls by default? Not fully. Always relay calls is off by default. One-to-one calls with contacts may use a peer-to-peer path that exposes IP addresses. Enable Always relay calls to force TURN relays. Group calls are not peer-to-peer.

Colin Aamot is an investigative journalist and OSINT domain expert specializing in FOIA and public records. A technologist, U.S. Army veteran, and former Capitol Hill staffer, he has held director roles across the private and public sectors.Full bio