[messaging] Panoramix decryption mixnet messaging spec and design documents

[dawuud]

Hi Michael,

> Hi David,
> 
> It's really exciting to see mix networks becoming an active area of
> interest again. Can I ask a couple of high-level questions about Panoramix?

Yes, questions welcomed!

> First, you're adding a reliability layer on top of Loopix, right? I can

Yes, indeed it could be articulated in that way. However we do not currently
have specifications for decoy traffic but we plan to in the future.

> see the usefulness of that, but I also wonder whether all applications
> will have the same reliability needs - in the IP world some applications
> use UDP rather than TCP, some use multicast, etc. To what extent is the

No. Not all applications have the same needs in a network transport protocol.

> reliability layer fused with the mixnet layer? If I wanted to use a
> different reliability layer (or none), which parts of the system
> (clients, mixes, providers) would I need to replace?

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.

Depending on the application, it is also possible to achieve
reliability without the use of ACKnowledge control messages. In this
thread I have previously mentioned my mixnet zcash transaction
transport idea where the blockchain is utilized in place of
ACKnowledge control messages in a Stop and Wait ARQ scheme. Here:

https://moderncrypto.org/mail-archive/messaging/2017/002368.html

and here:

https://moderncrypto.org/mail-archive/messaging/2017/002370.html

> Second, Loopix allows users to receive messages (via their providers)
> while they're offline, which is great. But for mobile devices there's
> another common situation, where the device is online but asleep. Email
> and messaging apps typically wake the device with a push notification
> when a message is available. On Android at least this can be done
> without going through Google's push service by keeping a connection to
> the provider open while the device is asleep. 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.

> expect timely notifications. Are push notifications something you've
> considered in the Panoramix design, and if not, would you be interested
> in including them?

Yes I agree it sounds interesting but ultimately it's not up to me. I
am more involved in the overall mixnet design and the user facing
intricacies have not been my primary concern here. We are working with
a k9mail/Android developer who will ultimately be making these kinds of
decisions.

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.


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/20170919/58ef1737/attachment.sig>