[messaging] Panoramix decryption mixnet messaging spec and design documents

[dawuud]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171121/6aa28926/attachment.sig>