[messaging] Panoramix decryption mixnet messaging spec and design documents

[Michael Rogers]

On 10/11/17 14:31, Ximin Luo wrote:
>> So if we're asking whether a system may be vulnerable to the attack, and
>> it has the properties above, then we need to ask whether the system is
>> doing something to produce that countervailing tendency. In other words,
>> is it actively preventing the attack?
>>
> 
> Indeed, I noted that the specific simple attack "assumes that nodes are unable 
> to use any other information to distinguish between faulty vs good neighbours.
> 
> There are various things you can do along those lines, and the paper you linked 
> includes a defense that based on their analysis is moderately effective. I'm 
> sure there are improvements to be made though.

Absolutely. I'm not saying the eclipse attack rules out decentralised
solutions. I'm saying any decentralised solution needs to specify how
it's going to prevent the attack.

If you think that's trivial, take a look at MorphMix and the attacks
against it, and the papers from 2006-2010 that tried to do anonymous
routing over P2P networks, or use P2P networks to replace the Tor
directory system. I think most of them are cited by these two papers:

https://www.princeton.edu/~pmittal/publications/information-leaks-ccs08.pdf

http://www.usenix.net/legacy/events/hotsec10/tech/full_papers/Mittal.pdf

Again, I'm not saying it's impossible and we should all go home, but
it's definitely not a problem to be dismissed out of hand.

>>> Going back to the original issue (epistemic attacks against mixnets), the key
>>> point AFAIU is to ensure that n ~= N. Whether this is achieved in a centralised
>>> or decentralised way seems immaterial to me.
>>
>> The question isn't really the size of the view, but how much overlap
>> there is between the views of different users. Even if a user has some
>> way to know the value of N in a decentralised system (which is a hard
>> problem in its own right), how does she know whether the n ~= N nodes in
>> her own view are also in other users' views?
>>
> 
> If n ~= N then the overlaps are much closer and you can follow the maths in the 
> rest of the paper to see that the attack probabilities drop to very low.

That's fine for analysing the system from outside, where the set of N
nodes can be objectively known. But a user of the system doesn't have
that objective knowledge. She has a view of n nodes, but she doesn't
know N, so she can't tell to what extent her view overlaps with those of
other users. This isn't just an issue of user confidence, it's also a
practical problem: how does she know when she's learned about enough
nodes to start communicating?

Going back to the wider issue of epistemic attacks on anonymity systems,
it may not even be necessary for a user's view to differ much from those
of other users. For example, if the attacker can add a single node to a
victim's view that's not in any other user's view, then any traffic
passing through that node must come from the victim. So even n = N for
the victim, and n = N-1 for all other users, doesn't ensure safety.

>> I'm not interested in writing off decentralised systems any more than
>> you are, but there's a burden of proof here. Given the existence of a
>> pretty broad class of attacks that only apply to decentralised systems,
>> a decentralised system needs to show it's not vulnerable to those attacks.
>>
> 
> The attacks only work if the decentralised system literally makes no effort to
> defend itself.

That would only be true if every effort was effective. Look at MorphMix,
for example. It had a clever defence to prevent an eclipse-like attack,
but the defence was defeated by modelling its internal state.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171110/cb605143/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171110/cb605143/attachment.sig>