Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

In the Loopix paper at the end of section 4.1.2 it says: """ If the number of messages in client’s inbox is smaller than a constant threshold, the provider gen- erates additional dummy messages. Thus, the adversary observing the client-provider connection, as presented on Figure 3, cannot learn

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> Can you explain that in some more detail? I don't see how it automatically > follows that, any attack that works on a typical deliver-by-push mixnet also > works with equal probability on a deliver-by-pull ("store-and-retrieve") > network - which is what you seem to be implying. Yes, I

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > >>> If my understanding is correct, the answer is No. No we cannot prevent >>> longterm intersection attacks by using decoy traffic in the >>> katzenpost/loopix system because users will go offline and come back >>> online later which changes the anonymity set size and thus leaks >>>

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> > If my understanding is correct, the answer is No. No we cannot prevent > > longterm intersection attacks by using decoy traffic in the > > katzenpost/loopix system because users will go offline and come back > > online later which changes the anonymity set size and thus leaks > > information

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > >> I wonder, in general can we have nice things? Can we finally have a >> cryptographic messaging system that protects against intersection >> attacks? To that end I've been putting together a reading list so that > > If my understanding is correct, the answer is No. No we cannot

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

german news article about panoramix and autocrypt/nextleap http://fm4.orf.at/stories/2877814/ On Tue, Nov 14, 2017 at 04:10:25PM +, dawuud wrote: > > > I wonder, in general can we have nice things? Can we finally have a > > cryptographic messaging system that protects against intersection

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> I wonder, in general can we have nice things? Can we finally have a > cryptographic messaging system that protects against intersection > attacks? To that end I've been putting together a reading list so that If my understanding is correct, the answer is No. No we cannot prevent longterm

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

OK... I've added three more papers to the references section of the mixnet directory authority rough draft specification: [FINGERPRINTING] "Route Finger printing in Anonymous Communications", . [BRIDGING] Danezis, G.,

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Michael Rogers: > On 10/11/17 14:31, Ximin Luo wrote: >>> So if we're asking whether a system may be vulnerable to the attack, and >>> it has the properties above, then we need to ask whether the system is >>> doing something to produce that countervailing tendency. In other words, >>> is it

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

On 10/11/17 14:31, Ximin Luo wrote: >> So if we're asking whether a system may be vulnerable to the attack, and >> it has the properties above, then we need to ask whether the system is >> doing something to produce that countervailing tendency. In other words, >> is it actively preventing the

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

On 06/11/17 13:29, Ximin Luo wrote: > https://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf > > This paper's description of the eclipse attack is as follows: > > "More precisely, routing updates from correct nodes point to a faulty node > with > probability at least f whereas this probability can

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Michael Rogers: > On 01/11/17 01:40, Ximin Luo wrote: >> After a quick web search on "epistemic attacks", the main paper I can find >> [1] has the result that attacks are very strong if each node only knows >> about a small fraction (n nodes) of the whole network (N nodes). >> >> They lay the

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> Directory authorities perform a different job, so I prefer to not call these > also "PKI". "Consensus service" would be less confusing - for me as a > security person but not specialised in anonymity research. Ah yes, I see your point. > > I've heard that I2p uses a completely different

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

On 01/11/17 01:40, Ximin Luo wrote: > After a quick web search on "epistemic attacks", the main paper I can find > [1] has the result that attacks are very strong if each node only knows about > a small fraction (n nodes) of the whole network (N nodes). > > They lay the motivation for this

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > [..] >> >> Indeed no, but I understand now and the comparison was useful, thanks. I >> think I was originally thrown off because the term "PKI" brought to my head >> X509 and WoT mapping of real-identities-to-keys. >> >> If I understand correctly, what you mean here instead is a

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> > Yes you are right to point out the vagueness in the PKI spec draft I > > sent you. Mixnets like Tor require a PKI that clients can query to > > gain a view of the network so that path selection is possible. Like > > Tor's Directory Authority system we need to store various bits of > >

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud writes: >> 2. Why is a PKI necessary? On a quick read, Loopix paper doesn't seem to >> mention this. You have a brief justification in pki.txt but the text does >> not make complete sense to me: "it gives each client the same view of the >> network, it links mix IDs

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

replying inline On Mon, Oct 30, 2017 at 09:19:00AM +, Ximin Luo wrote: > dawuud: > > No, it will scale as Loopix intended. The constraint that each Operator > > will run an equal size set of mixes is a deployment constraint that may > > not be adhered to strictly. We shall see, for now we

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > No, it will scale as Loopix intended. The constraint that each Operator > will run an equal size set of mixes is a deployment constraint that may > not be adhered to strictly. We shall see, for now we haven't even finished our > implementation so we are a ways away from discovering what

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> Yes you are right to point out the vagueness in the PKI spec draft I > sent you. Mixnets like Tor require a PKI that clients can query to Of course I'm not saying that mixnets and Tor are the same... whereas Tor does no mixing. Although the similarities are useful when discussing the PKI

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> 1. The Loopix paper mentions "Furthermore, many mix nodes can be securely > added to a stratified topology to scale throughput" but your mixdesign.txt > states "Operators are a part of a fixed set who all agree to cooperatively > run an equal size set of mixes and network perimeter points".

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > > https://github.com/Katzenpost/docs/blob/master/drafts/mixdesign.txt > > [..] Hi David, it's been a while since I read through this topic, and I only briefly scanned the Loopix paper, so forgive me if the following questions are ignorant: 1. The Loopix paper mentions "Furthermore,

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> > the key material between the two orientations. You could achieve that > > split by building a SURB, and doing so may simplify the code elsewhere > > or even enable multiple-ACKs, but it's nowhere near as messy as folks > > imagine when they hear you say SURB though. > > Actually, I think

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> On Sat, 2017-09-16 at 22:21 +, dawuud wrote: > > On the other hand the Loopix design as described in the paper does not > > include any message reliability mechanism at all. In our design we do > > not use the SURBs to achieve any identity-hiding property like > > Mixminion does. Instead we

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Hi Michael, > 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

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

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

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

replying inline... > > 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

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

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

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

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

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

On 09/08/17 03:53, dawuud wrote: > I just wanted to make you all aware that I've published our design > and specification documents for our mixnet project: > > https://github.com/Katzenpost/docs Hi David, It's really exciting to see mix networks becoming an active area of interest again. Can I

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

On Sun, 2017-09-17 at 08:43 +, dawuud wrote: > Sweet! I'm looking forward to reading this mountain of pros you've produced. > As I've mentioned before, I'm a fan of your work. It's almost all 5+ months old now, probably the last real additions were due to a brief chat about ACKs with George

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Jeff, > I've an unfinished document that analyzes different forms the Sphinx > packet format might take : > https://github.com/burdges/lake/tree/master/Xolotl/papers Sweet! I'm looking forward to reading this mountain of pros you've produced. As I've mentioned before, I'm a fan of your work.

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Trevor, I've an unfinished document that analyzes different forms the Sphinx packet format might take : https://github.com/burdges/lake/tree/master/Xolotl/papers It's true, cross over points and SURBs add complexity to the implementation, and make the header larger, but actually they do not

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

> Hi David, Hi Trevor, > Hope you don't mind belated comments: That's a very thoughtful message you have written and I really appreciate it. I'm hoping my mixnet design collegues will join this discussion because they have lots of ideas on the subject and our specs are filled with many

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

On Wed, Aug 9, 2017 at 2:53 AM, dawuud wrote: > > I just wanted to make you all aware that I've published our design > and specification documents for our mixnet project: > > https://github.com/Katzenpost/docs [...] > https://github.com/Katzenpost/docs/tree/master/specs