burdges
commented
5 years ago I'll note my second and preferred solution of recording body hashes requires that replay protection use cuckoo filters instead of bloom filters.
Open burdges opened 5 years ago
burdges
commented
5 years ago I'll note my second and preferred solution of recording body hashes requires that replay protection use cuckoo filters instead of bloom filters.
We cannot always MAC the body because receivers cannot know the packet bodies they receive, only the SURBs they give out.
As a result, there is a 1 bit tagging attack on senders: Our sender's guard corrupts the packet body and the receiver or whoever detects the corruption knows the received a corrupted packet. In any protocol, receivers who respond are inherently vulnerable to a similar attack, so this cannot be considered disastrous, but..
There are schemes which defend against this by having everyone receive some garbage packets, but if everyone's incoming packets were generated by their own SURBs then this becomes harder to enforce, but not necessarily impossible. There are plausible similar solutions that align well with gossiping node PKI information, meaning you give out some SURBs randomly and sometimes you get gossiped nodes, sometimes you get garbage, and sometimes you get a request to prove you constructed the packets honestly.
We'll ignore these cover based ideas for now to discuss cryptographic solutions:
We could give senders to have an optional MAC_BODY routing command, which exposes that a packet is in the outgoing part of its route, but not necessarily which hop. If executed at a malicious node, then this provides no protection, but if executed by an honest node then this provides strong protection. This increases the routing info by like 17 bytes per expected MAC_BODY command.
We could record a few bytes from
H(s ++ body)in the replay protection database, so that anyone corruption packet bodies tends to get exposed by the proof-of-mixing payment scheme. I suppose this provides weaker protection for each individual packet, but overall this operates without leaking any details about real packets and operates basically all the time. Also it may provide some limited protections for receivers, except that maybe sender corrupt their own packets there. This increases the replay protection database size.I prefer this last solutions. I'll add this discussion to my packet format discussion document.