[messaging] Panoramix decryption mixnet messaging spec and design documents

[dawuud]

replying inline

On Mon, Oct 30, 2017 at 09:19:00AM +0000, Ximin Luo wrote:
> 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?

No I cannot go into detail because I don't have details like that.
Maybe someone else involved in the project can answer this question for you.

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

I do not agree that PKI is the wrong word to use. I am using the term
PKI in the same way that much of the mixnet literature uses it. And
when working with George, Ania and Claudia we used the PKI term as
well.

Yes I think your understanding here is correct however I would have
stated that it is a mapping between the identity and the
descriptor. That the identity is a public key is true... as it will be
in our Directory Authority (PKI) system as well.  I don't know what
you mean by "real".

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

Indeed PKI appears once because they adopt the terms of Nick Mathewson
and call the PKI servers Directury Authority servers.

The Sphinx paper also has the term PKI exactly once:

"We assume the presence of a PKI that publishes an authenticated list of all (n, y n ) pairs."

Yes that one sentence in the [MIRANDA] paper could be more articulate
but I don't think it is incorrect. If the authors were working on a
specification I'm sure they would write down different details and use
the term descriptor since mapping identities to keys clearly isn't
enough.

> 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").

This [MIRANDA] paper is a departure from what we are trying to do
since they are using the PKI and other mechanisms to defend against
n-1 attacks whereas the Loopix design uses decoy traffic loops to
detect n-1 attacks. That having been said I think it's a brilliant
paper and I'd to implement something like it in the future.

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

Good question. I would also be greatful if anyone on this list could
point us to papers that talk more about the security properties of
consensus-based PKIs/Directory Authority system.  I don't know of
any. I don't understand why you think social networks and strengths of
social connections is relavant... but maybe it is. Really, the voting
protocol that mixminion and Tor use is a deterministic document
generation algorithm.

   [MIXMINIONDIRAUTH] Danezis, G., Dingledine, R., Mathewson, N.,
                      "Type III (Mixminion) Mix Directory Specification",
                      December 2005, <https://www.mixminion.net/dir-spec.txt>.

   [TORDIRAUTH]  "Tor directory protocol, version 3",
                  <https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt>.

I've heard that I2p uses a completely different kind of PKI... involving a
gossip protocol. I suspect it is highly vulnerable to epistemic attacks which
is supposed to be one of the main reasons to use a design like Nick's.


Cheers,
David
-------------- 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/20171030/45ef76ce/attachment.sig>