[messaging] Panoramix decryption mixnet messaging spec and design documents

[Michael Rogers]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20170921/df6174c3/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20170921/df6174c3/attachment.sig>