[SPAC] Metadata privacy from intermediaries

[andrewzhurov]

I've read the paper a couple of times, but there may be mistakes in my understanding, hope for corrections when so.

Triple nested protocol describes a way to hide actual two AIDs that communicate from intermediaries by establishing communication context over a routed context. The header portion of ESSR message from source to destination is plaintext seen by intermediaries as they route the message, allowing one to aggregate. Additionally, first hop and last hop know exact IP (of source and destination respectively, which might allow for re-correlation(?). Similar to entry/exit node compromise in Tor - no matter how many hops a message takes compromiser knows source and destination IPs.

Routed context may be "refreshed" periodically to new routed AIDs as a way to cater for source<>destination message aggregation by intermediaries that are in the middle of hops' chain; seems, those entry/exit ones might be able to correlate IP -> previous routed AID.

If those concerns are valid, perhaps the root cause is that any given intermediary knows source and destination?
(well, entry node can't know for certain if the sender is source, but could guess with high probability, e.g., dynamic IP - likely source; exit node knows for certain destination)

Anyhow, would it be desirable to have intermediaries unaware of both source and destination of any given message?

Recursive XHOP, seems to me about having nested HOP payloads encrypted by sender per-hop, onion-style. Where each hop peels one layer to learn the next hop receiver + encrypted to it HOP. This makes it so the full path is not known to any given node. Could be traced only if all nodes are compromised. Am I correct in its interpretation?

Still, if last hop intermediary / exit node, sees ESSR from source to destination, being a colluder with entry node they'd learn source IP destination IP. But that seems to be addressed by the recent Hop Payload Encrypted to Final Destination proposal, if I'm correct? Making so exit node only knows sender (and isn't sure whether it's destination? Would be so if we use recursive HOPs, encrypted per-intermediary - exit node doesn't know whether than encrypted payload to sender (destination) is yet another HOP or actual message's content)

Hope I wasn't too far off in my reasoning..

[SmithSamuelM]

Sent from my iPadOn Jul 28, 2025, at 09:50, Andrew Zhurov ***@***.***> wrote: I've read the paper a couple of times, but there may be mistakes in my understanding, hope for corrections when so. Triple nested protocol describes a way to hide actual two AIDs that communicate from intermediaries by establishing communication context over a routed context. The header portion of ESSR message from source to destination is plaintext seen by intermediaries as they route the message, allowing one to aggregate. Additionally, first hop and last hop know exact IP (of source and destination respectively, which might allow for re-correlation(?). Similar to entry/exit node compromise in Tor - no matter how many hops a message takes compromiser knows source and destination IPs.There is a nuance here.  The assumption is that the first intermediary is somewhat trusted by the source and the last intermediary is somewhat trusted by the destination. The correlation minimization is with regard to some external party that is not the somewhat trusted intermediary.  The fan-into the first intermediary means that looking backwards a correlator can’t correlate the first hop without compromising the first intermediary because of the herd privacy granted by the fan in.  Likewise the fan-out of the last intermediary means that looking forward a correlator can’t correlate the last hop because the fan-out of the last intermediary provides herd privacy to the last hop.  But that is just with two layers of nesting., The third layer means that no intermediary sees the AIDs used in the third layer, so there is zero correlation between those AIDs and any IP addresses.   So if those AIDs show up some where a surveillor that is colluding with any or all the intermediaries can’t correlate those AIDs via SPAC to any IP address without breaking encryption at the third layer of nesting. Looking at packet TOD, TOA, Size at likely endpoints doesn’t allow correlation to the AIDs at the nested third layer.  Given that one is communicating between AIDs means that one does not have to use stable IP addresses for those AIDs. A given discussion could be distributed across multiple destination IPs and then reassembled to the AID.The fact that two IP addresses are communicating can never be decorrelated as long as the packets are routed over the open internet. Onion routing doesn’t ultimately protect against this. This is a nuance.  If I know the source but do not know a “likely” destination then with a big enough guard on my onion routing there may be enough herd privacy so that a survellior loses track before it reaches the destination. But if the survelllior has a guess of one of some large set of “likely” destination which most survelliors already do. I.e. is the destination on a watch list, then its doesn’t matter what route the packets take or how obscure the routing,  the TOA, TOD, and packet size of a message steam (TCP connection) will correlate the two endpoints.  One would have to add random time delays, change packet sizes in random ways etc. I.e. not use TCP Use UDP with a lot of extra randomness thrown in.  Which TOR does not do.If one only uses TOR to hide communication with problematic destinations then the fact of using TOR makes the correlator’s job easier since the list of “likely” destination just got very small relative to the whole internet.It only makes sense to use SPAC when one uses it for all ones communications. This way ones own traffic provides correlation minimization.  I hope this helps.   Routed context may be "refreshed" periodically to new routed AIDs as a way to cater for source<>destination message aggregation by intermediaries that are in the middle of hops' chain; seems, those entry/exit ones might be able to correlate IP -> previous routed AID. If those concerns are valid, perhaps the root cause is that any given intermediary knows source and destination? (well, entry node can't know for certain if the sender is source, but could guess with high probability, e.g., dynamic IP - likely source; exit node knows for certain destination) Anyhow, would it be desirable to have intermediaries unaware of both source and destination of any given message? Recursive XHOP, seems to me about having nested HOP payloads encrypted by sender per-hop, onion-style. Where each hop peels one layer to learn the next hop receiver + encrypted to it HOP. This makes it so the full path is not known to any given node. Could be traced only if all nodes are compromised. Am I correct in its interpretation? Still, if last hop intermediary / exit node, sees ESSR from source to destination, being a colluder with entry node they'd learn source IP destination IP. But that seems to be addressed by the recent Hop Payload Encrypted to Final Destination proposal, if I'm correct? Making so exit node only knows sender (and isn't sure whether it's destination? Would be so if we use recursive HOPs, encrypted per-intermediary - exit node doesn't know whether than encrypted payload to sender (destination) is yet another HOP or actual message's content)The HOP excrypted to final destination is not as good at triple layer nesting since in triple layer nesting the final destination is already encrypted as well as the payload.  The HOP encrypted to final destination is good when you are taking to yourself so you don’t care if the source can correlate the destination since they are the same entity just distributed in extent. So its more efficient that triple nesting not more secure. Hope I wasn't too far off in my reasoning.. SPAC.png (view on web) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>