[messaging] Panoramix decryption mixnet messaging spec and design documents
dawuud at riseup.net
Mon Oct 30 11:37:57 PDT 2017
> > 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.
> Might be worth mentioning here that Tor's design does not actually
> ensure that "each client should receive the same network consensus
> There are multiple valid consensus documents at every point in time, and
> each client should have a valid one, but that doesn't mean they all have
> the same one.
> The Tor network makes a consensus document every 60 minutes, and clients
> are not instructed to immediately fetch it because that would cause a
> "thundering herd" problem. So each client has its own consensus download
> schedule, which means that different clients will have different consensuses.
> Not sure if that invalidates any loopix assumptions but thought it might
> be worth mentioning it.
Thanks for the correction! Yes and it seems like if there are only a small number
of valid consensus files at any given time then this should serve to eliminate
epistemic attacks on client's view of the network.
Oh look, slides about mixnets by George Danezis here:
On slide 16 he mentions:
"""Problem: all clients need to use the same information to construct paths
through relays. Otherwise: attacks based on knowledge of the client
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Messaging