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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Messaging mailing list
Messaging@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to