Hi David, On 21/09/17 14:58, dawuud wrote: > Our Stop and Wait ARQ scheme terminates on the destination Provider. > If it was client to client then both clients would have to be online > at the same time.
Thanks for explaining, that makes sense. >> But I think the mix layer has been adapted to the needs of the >> reliability layer to some extent by adding SURBs, right? And in a > > No. The mix net gives zero fucks about reliability. > Fundamentally mixnets are an unreliable packet switching network. Sure, I understand that the mixnet is an unreliable packet switching network. And then there are some other pieces - reply blocks, flow control, ARQ - that are implemented by higher layers, or maybe implemented by the mixnet and used by higher layers. I'm trying to understand how the pieces fit together. >> previous message you mentioned "source quench" from mixes to providers. > > No. I didn't. Trevor mentioned it. This is an implementation detail > and is more related to flow control. It's definitely not part of any > ARQ protocol scheme. Sorry for attributing the quote to the wrong person. I'll go and read the specs to understand how flow control fits into the bigger picture. > I suggest you read up on ARQ protocol schemes. Wikipedia has some decent > articles > on the subject. There's a vast amount of literature on this subject which may > help clear up your misunderstanding of what reliability means in the context > of an unreliable packet switching network. I have a fairly good understanding of ARQ and general networking concepts. What I'm trying to understand is how those concepts are used in the Katzenpost architecture. Ultimately I'd like to understand what my options are for building applications on top of Katzenpost. >> there are other considerations for mobile clients: decoy messages >> consume bandwidth and power, and a mobile app may not be able to wake up >> to send decoy messages on an arbitrary schedule. So my broader question >> is how much control an application using Panoramix, or even an >> individual client, will have over the decoy traffic parameters, and how >> those choices will affect anonymity. > > By the way the name Panoramix refers to a much bigger project than this > decryption mixnet. So far we've named our implementation Katzenpost > because the committee hasn't told us to rename it yet. > > This is really a question about the Loopix paper if you are asking about > the anonymity set size on mixes versus decoy traffic versus legit traffic. Good point, I'll ask the Loopix authors about that part. > On the other hand your question is also essentially a trick question > because you are assuming that the application's interface with the > mixnet includes control over decoy traffic whereas from my perspective > the mixnet is designed to support specific applications and therefore > the appropriate decoy traffic will have already been selected. > > Or said another way: "Do you really think an e-mail client should let > the user select the frequency of decoy messages sent over the mixnet?" Ah, thanks for explaining. I thought the goal was to build a general-purpose mixnet infrastructure on which people could build as-yet-unknown applications. Hence all the questions about what options are available to applications and what interfaces are exposed by different layers. But even if the goal is just to support specific applications, I wonder if it would be useful for clients (by which I mean mixnet clients, not MUAs) to have some control over decoy traffic, because different clients will have different constraints. For example, a desktop client may prefer different power/bandwidth/anonymity tradeoffs to a mobile client. Cheers, Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
