> Can you explain that in some more detail? I don't see how it automatically > follows that, any attack that works on a typical deliver-by-push mixnet also > works with equal probability on a deliver-by-pull ("store-and-retrieve") > network - which is what you seem to be implying.
Yes, I think I was wrong about that... Katzenpost is delivery by pull as well. Clients retreive messages from their Provider. This paper: [DUMMYINTERSECTION] Berthold, O., Langos, H., "Dummy Traffic Against Long Term Intersection Attacks", In the Proceedings of the PETS 2002, <https://www.freehaven.net/anonbib/cache/langos02.pdf>. mentions that there are some constraints needed for the intersection attack to work: a. the adversary is able to watch all user lines b. the adversary is able to watch all Provider/server lines (see figure 1 in paper) c. the adversary knows how long it takes for a message to traverse the mix network d. messages belonging to a certain session have to have the same property that allows the adversary to link them each together So in Katzenpost I don't think constraint "c" is met since we aren't using synchronized batch mixing... but rather the Poisson mix strategy where clients select the mix delay for each hop in the route which should be different for every sent message, even retransmits... although client route hop delays are sampled from an exponential distribution. The attacker can of course compute the probability of a certain route delay having been choosen by a client. I also cannot think of a way that "d" is met... unless of course there is collusion with the destination Provider. > For example, in a deliver-by-push network, an attacker knows roughly how long > a message is expected to take to cross the network, and this is the same for > everyone. In a deliver-by-pull network, different users may retrieve their > messages at different times and so the attacker no longer has this power. Or, > they can attempt to infer it but (a) it will be different for each message > and (b) they have less confidence in their results. In Katzenpost, users retrieve their messages directly from their own Provider and do not use the mix network when retrieving queued messages. Although the Provider always sends the same amount of stuff to the client... so that interaction cannot be used to discover is a client has actually retrieved a message. Although the adversary could attempt to link messages delivered to the destination Provider with messages sent by online clients. Further, and then discover all the clients that download messages from that Provider are in the set of suspect recipient clients. That's as far as I can imagine this attack going... but then I haven't read all the papers on the subject yet. > One might even be able to do tricks like, to retrieve a message of size X you > have to send a request of size X. That might make it harder for an attacker > to distinguish between senders and recipients. All katzenpost messages are padded to the same size and we have a fragmentation scheme for messages larger than this. > > Yeah that sounds good... although having client to client ACKs means they > > both have > > to be online at the same time which is a constraint that is probably > > inconvenient > > unless it's treated like a real-time chat application. > They don't have to be online at exactly the same time, the application can > choose what time interval the ACKs are expected to arrive within. Depending > on the application this could be a few minutes to a few days. It's also > conceivable to adjust this timeout based on application-specific information. Yes that's true. Maybe we'll add the end to end ACKs later. > Of course, I agree that ACKs that are sent too predictably, will give more > information to an attacker. Yes and if the adversary causes an ACK to get dropped or delayed then this results in a retransmission from the sending client. Although this shouldn't be a problem since clients send stuff at a constant rate (unless we implement source squelch to try and prevent congestion collapse). > >> Wasn't Jeff Burdges exploring designs in this area at some point? I > >> vaguely remember him talking about it at various events a few years ago. > > > > Yeah Jeff Burdges has been doing some very interesting mixnet research. > > Some of his designs are here: > > > > [..] > > Thanks for the links, will have to be another day when I go through them > properly. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging