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
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging