[messaging] Panoramix decryption mixnet messaging spec and design documents

[dawuud]

> 1. The Loopix paper mentions "Furthermore, many mix nodes can be securely added to a stratified topology to scale throughput" but your mixdesign.txt states "Operators are a part of a fixed set who all agree to cooperatively run an equal size set of mixes and network perimeter points". Hopefully I'm understanding you wrong but it sounds like:
> 
>   a) The proposed network won't scale as Loopix intended to.

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.

What is to be understood here about the stratified topology for mix
networks is that it the best option we have because it scales well,
has slightly better entropy than free route topology, much easier to
prove entropy than free route and allows for a fixed set of perimeter
mixes in this case we call them Providers. Whereas most mixnet papers
end up writing about cascade topology which doesn't scale well at all.

>   b) There are additional trust requirements/assumptions that Loopix doesn't require.

The Loopix design does use the same model we are implementing where Provider authenticate clients.

> Could you clarify?
> 
> 2. Why is a PKI necessary? On a quick read, Loopix paper doesn't seem to mention this. You have a brief justification in pki.txt but the text does not make complete sense to me: "it gives each client the same view of the network, it links mix IDs to public routing keys."
> 
>   - If by "same view" you mean "same view of crypto identities" then this suggests the network can't scale, as I was worried about above.
>   - If by "same view" you mean "same view of online/offline nodes" I think this is impossible to achieve due to well, networks being unreliable.
> 
>   If mix IDs are simply the public routing keys themselves, does that avoid the need for a PKI? I suppose you still need to map public keys to physical addresses, but there's probably an existing system you could re-use for that purpose.

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

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

> 3. "The PKI also needs to hold network wide parameters."

I meant network parameters that cannot otherwise be detected such
as the Poisson mix strategy lambda parameter that all clients must
use with selecting their route hop delays.

>   - Why is this necessary, why can't each mix node detect this by itself? If they rely on a "PKI" for these parameters, doesn't the "PKI" hold some position of power over the network?

The PKI is the root of all authority in the network... it can decide
which mixes belong and what certain network parameters are set
to. This is also why making the PKI/Directory Authority into a
decentralized system is a good idea.

>   - How do these parameters relate to the exponential/poisson RV parameters mentioned in the Loopix paper? Do those parameters also need to be uniform across all mix nodes? I suppose not, since it is supposed to defend against malicious mix nodes, but perhaps "most honest nodes" need to agree on the same parameters. In any case, I don't see the point being explained in great detail. (Again, this on a quick reading; I might have missed something.)
> 
> Those are the specific questions. Apart from that, it would be good if you could summarise the differences between your design and Loopix plus some motivation on why. (Because people like me naturally ask "why not just do Loopix".)

We are essentially doing the Loopix design here. Ania, the primary
author of the Loopix paper spent 3.5 months with us in our
design team working on these specifications. We are adding to it's
design: reliability via Stop and Wait ARQ.

Also... we didn't get around to specifying decoy traffic and we intend
to do this later.

> I gather that you do already talk about this elsewhere, it just would be nice to have it collected together in a separate document. For example the Loopix paper has a Section 6 "Related Work" and a Table 2 that summarises this - it was very nice to read that, especially for me who hasn't looked at this topic for a significant time.
> 
> In particular, it would be good if you could talk a bit about how your differences, affect Loopix's original security properties. I think Section 2.3 "Security Goals" is quite a nice summary of what it's trying to achieve. If you could confirm that is indeed what your system is also aiming for, together with any other security properties it doesn't mention, it would be much easier to evaluate.

Well... Stop and Wait ARQ is vulnerable to active confirmation
attacks... like say an attacker causes the ACK packet to get
dropped. In this case the sender would retransmit. However we intend
to specify decoy traffic at some point in the future which should
mitigate this kind of confirmation. Perhaps it would be less
reassuring had we decided to use Go Back N ARQ or Select Repeat ARQ
where missing ACKs cause more packets to be retransmitted.

Yes, in summary our mixnet will have all the same security goals as
Loopix but will not practically achieve most of them until the decoy
traffic is specified.


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/20171028/124227e0/attachment.sig>