What is metadata, and does encryption hide it?

Every message has two parts: what it says, and the information needed to deliver it. Signal compares this to physical mail. The service cannot see into the encrypted package, but it uses what is written on the outside to deliver it, and traditionally that includes both the sender and the recipient.

That outside information is metadata. It usually answers four questions:

• Who. The sender, the recipient, and for groups, who the members are.
• When. The time a message was sent and how often messages flow.
• How much. The size of each message and the volume of traffic.
• Where. The network address a message came from, and on local radios, the physical place a device was seen.

Metadata matters because it can be revealing on its own. RFC 9750, the MLS architecture document, notes that even fields that look harmless can let a network observer reconstruct sensitive information when they are correlated with other data.

End-to-end encryption protects content. It was not designed to hide the envelope, and most systems leave several parts of it exposed.

The network sees endpoints. The Tor Project explains that every internet packet carries a source and destination address, and every router along the way learns that the sender is communicating with the receiver. A local internet provider is in a position to build a profile of a person’s internet use.

Group protocols expose some structure. RFC 9420 lists what MLS does not keep confidential, including key packages, the unencrypted header fields of encrypted messages, and the lengths of encrypted messages. From these, an observer might infer the group’s identifier, its current epoch and how often the group changes, how often messages are sent and who the members are. MLS is designed on the assumption that the transport layer keeps metadata private from network observers, and RFC 9750 recommends running it over TLS or QUIC.

Formats state their own limits. NIP-44, the encryption format used on Nostr, lists them plainly: relays and intermediaries may see a user’s IP address, the timestamp is public, and padding only partially hides message length.

Hiding metadata takes extra design, and each technique covers part of the envelope.

• Sealed sender. In 2018 Signal described a way to drop the sender from the outside of the envelope. The sender’s certificate travels inside an encrypted envelope addressed to the recipient, and the message is handed to the service without authenticating. Signal said resistance to traffic correlation through timing and IP addresses was still being worked on.
• Gift wraps. Nostr’s NIP-59 wraps an encrypted event inside another one signed by a random, one-time key, and says timestamps on the outer layers should be tweaked to resist time analysis. How can a relay carry a message it cannot read? describes the layers.
• Padding. NIP-44 pads each message before encrypting it, using sizes related to powers of two, so the ciphertext reveals less about the true length. It still describes this as only a partial fix.
• Onion routing. Tor encrypts traffic in layers and sends it through a series of proxies, so the local provider sees only that a user is talking to Tor. It has limits: the Tor Project says an observer who can watch both ends of a connection can correlate timing, and Tor does not defend against that threat model.

RFC 9750 recommends MASQUE, Tor or a VPN where privacy or anonymity is important, and notes that anonymous credentials alone might not be enough.

Local radios have their own envelope. Bluetooth devices announce themselves through advertising, and the Bluetooth SIG notes that advertising packets contain a device address, which a hidden receiver could log with the time and place to track someone.

The countermeasure is a feature the SIG calls Bluetooth LE Privacy, available since Bluetooth Core 4.0. It replaces the address in advertising packets with a random value that changes at intervals the manufacturer chooses, so a series of sightings looks like different devices. Devices that have paired share an Identity Resolution Key, which lets them recognise each other’s changing addresses.

Application data sent over the radio can leak metadata too. Offline Protocol’s security docs give an example: in its mesh SDK, service advertisements and requests are signed plaintext, readable by any observer, and its Nostr sealing protects content but not all traffic metadata.

Hiding every piece of metadata is rarely possible, so the practical step is to decide which parts matter for your users.

• Assume carriers see timing, volume and network addresses unless you add a layer that hides them.
• Keep sensitive data out of fields that travel in the clear, such as headers, labels and advertisements.
• Treat group membership and contact lists as sensitive in their own right.
• Write down what each server, relay and nearby observer can learn, and review it when the design changes.