[messaging] Panoramix decryption mixnet messaging spec and design documents

[Michael Rogers]

On 19/09/17 18:44, dawuud wrote:
> End to end reliability can only be achieved using an Automatic Repeat
> reQuest protocol scheme which resides in the client. If you do not
> require reliability then the client becomes a lot simpler in it's
> design and implementation.
> 
> Take a moment to consider what might happen if we tried to make the
> mix network reliable without involving the client. In this case we
> could implement some sort of store and forward mechanism in each
> component mix... but ultimately if there is a mix outage this cannot
> guarantee reliable transmission of messages.
> 
> We have intentionally designed the client to be smart and the network
> components to be relatively dumb in accordance with the End to End
> Principle.

Thanks, that's good to know. So does this mean the mixes and providers
aren't involved in reliability at all - it's all client to client?

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
previous message you mentioned "source quench" from mixes to providers.
So I'm trying to understand which bits of the reliability design are
provided by which components.

Maybe I just need to read the specs, but I was hoping you could give me
an overview.

>> Sending a notification as
>> soon as a message arrives at the provider exposes more metadata to a
>> global passive adversary than holding onto the message until the user
>> polls for it - but on the other hand users of some applications may
> 
> That is only a correct statement if there is no decoy traffic to the
> client whereas we expect to specify decoy traffic in future revisions
> of our design. If you pay close attention to the Loopix paper, you'll
> see that it specifies several types of decoy traffic, some of which
> terminate on the client. These are important aspects of the Loopix
> design that should not be ignored.

Don't worry, I didn't ignore them. :-) I've read the paper but I'm
interested in what design choices will be implemented in Panoramix.

In the case I was talking about above, where the client's online but
asleep, a network observer may be able to distinguish a decoy message
that's silently consumed by the client from a real message that turns on
the screen, causing other applications to wake up and hit the network.

That's just one scenario and I don't want to get hung up on it, but
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.

> That having been said, I can tell you that the current rough draft
> client I have written has a SMTP submition proxy and a POP3 receive
> proxy that are meant to run locally on the client's endpoint
> device. This flexible design blurs the definition of "client".
> 
> This mixnet client as written performs periodic polling of the
> Providers for which the user has an account. I'm willing to change the
> implementation of the client if our Android developer wishes it,
> however the primary goal of using SMTP and POP3 as interaction
> mechanisms was to avoid heavily modifying the k9mail client to perform
> lots of crypto operations. This was mainly done because we do not wish
> to write our mixnet crypto libraries in multiple languages at this
> time. Our code base is all in golang whereas k9mail is written in
> Java.
> 
> Of course this also means that our current "client" should work
> with well with all e-mail clients that use SMTP and POP3.

It's great to know you're working with k9mail - I'm excited to try out
the client, and then I can start pestering you with specific questions
rather than vague ones. ;-)

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/2f52c3df/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/2f52c3df/attachment.sig>