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
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
