[messaging] Panoramix decryption mixnet messaging spec and design documents

[Ximin Luo]

dawuud:
> No, it will scale as Loopix intended. The constraint that each Operator
> will run an equal size set of mixes is a deployment constraint that may
> not be adhered to strictly. We shall see, for now we haven't even finished our
> implementation so we are a ways away from discovering what works for deployments.

Can you go into that in a bit more detail, e.g. what does "deployment constraint" mean, cost constraints? What happens if one operator runs 10 times as many provider-nodes as any other operator?

> [..]
>> Yes you are right to point out the vagueness in the PKI spec draft I
>> sent you.  Mixnets like Tor require a PKI that clients can query to
> 
> Of course I'm not saying that mixnets and Tor are the same... whereas
> Tor does no mixing.  Although the similarities are useful when
> discussing the PKI because they both have similar needs.
> 

Indeed no, but I understand now and the comparison was useful, thanks. I think I was originally thrown off because the term "PKI" brought to my head X509 and WoT mapping of real-identities-to-keys.

If I understand correctly, what you mean here instead is a service to provide consistency guarantees for the nodes in the network, so that they have some confidence they're talking to "the right network" and that they're not getting eclipse- or sybil-attacked. AFAIU the tor consensus system identifies each node using the node public key, so real-identities are not relevant. Then it also provides mappings between these keys/ids and their physical addresses.

> Ania also coauthored another recent paper about mixnets that has some
> interesting uses for their PKI to help prevent byzantine or n-1 attacks:
> 
>    [MIRANDA] Leibowitz, H., Piotrowska, A., Danezis, G., Herzberg, A., 2017,
>              "No right to ramain silent: Isolating Malicious Mixes"
>              <https://eprint.iacr.org/2017/1000.pdf>.
> 

The term "PKI" appears once in this paper: "We assume a PKI providing an authoritative mapping between mixes and their public keys." It sounds like they mean a real-identities-to-keys mapper rather than a consistency provider or a address-to-keys mapper.

Consistency and consensus are not explicitly mentioned. Instead they mention community detection, which is a *different* strategy for providing similar security properties (i.e. that you're talking to "the right network").

In other words, it seems to me they're not using the term "PKI" in the same way that you're using that term. 

>> gain a view of the network so that path selection is possible. Like
>> Tor's Directory Authority system we need to store various bits of
>> information about each mix in say, a "mix descriptor".
>>
>> By "same view" I mean each client (just like in Tor) should receive
>> the same network consensus document. The client uses this for path
>> selection.
>>

Do you know of any papers that quantify the security guarantees around consensus-based approaches? I'm not aware of any, and it would be good to read some if they exist. I do know that community-detection-based systems do quantify their security in terms of probabilities of reaching malicious nodes, based on various quantified assumptions about the link distribution of social networks and strengths of social connections. It would also be good to be able to quantifiably compare the two approaches.

>> To be clear, we are totally punting on the load balancing problem because it's hard.
>> However, the new Peer Flow paper looks promising:
>>
>>    [PEERFLOW] Johnson, A., Jansen, R., Segal, A., Syverson, P.,
>>               "PeerFlow: Secure Load Balancing in Tor",
>>               Preceedings on Privacy Enhancing Technologies, July 2017,
>>               <https://petsymposium.org/2017/papers/issue2/paper12-2017-2-source.pdf>.

Thanks for the pointer!

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: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171030/517bf748/attachment.sig>