[messaging] Panoramix decryption mixnet messaging spec and design documents

[Ximin Luo]

dawuud:
> 
>>> If my understanding is correct, the answer is No. No we cannot prevent
>>> longterm intersection attacks by using decoy traffic in the
>>> katzenpost/loopix system because users will go offline and come back
>>> online later which changes the anonymity set size and thus leaks
>>> information to a global network observer.
>>>
>>> I suspect that there are mixnet use cases which are not vulnerable or
>>> less vulnerable to this... such that user or application behavior does not
>>> form a "session" where users send multiple messages over long periods which
>>> can be linked by a passive observer.
>>>
>>
>> What about a store-and-retrieve design? You don't send "to" the receiver (not even indirectly), you send to a mailbox at an unpredictable address (or addresses) in a DHT-like distributed storage system, which is always online. Later, the receiver logs on and retrieves their own messages from their mailbox.
> 
> (none of that prevents longterm intersection attacks)
> 

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.

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.

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.

> oh yes i love these ideas... and i was previously discussing them with
> str4d in the context of i2p bote mail which is described here:
> 
> https://github.com/i2p/i2p.i2p-bote/blob/master/doc/techdoc.txt
> 
> This spec is a bit encumbered by crypto packet format details whereas
> I would just use Sphinx.
> 
>> Storage nodes only store stuff for a fixed amount of time and then they drop it, to save space / prevent storage DoS attacks. Participants rely on end-to-end acks to guarantee reliability. If the recipient doesn't ack your message, you assume the network dropped it, and resend it, perhaps to a newly-generated unpredictable address.
> 
> 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.
> 
> I like that this prevents some storage DoS attacks.
> 

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.

Of course, I agree that ACKs that are sent too predictably, will give more information to an attacker.

>> 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