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, 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". Hopefully I'm understanding you wrong but it sounds like: a) The proposed network won't scale as Loopix intended to. b) There are additional trust requirements/assumptions that Loopix doesn't require. Could you clarify? 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 to public routing keys." - If by "same view" you mean "same view of crypto identities" then this suggests the network can't scale, as I was worried about above. - If by "same view" you mean "same view of online/offline nodes" I think this is impossible to achieve due to well, networks being unreliable. If mix IDs are simply the public routing keys themselves, does that avoid the need for a PKI? I suppose you still need to map public keys to physical addresses, but there's probably an existing system you could re-use for that purpose. 3. "The PKI also needs to hold network wide parameters." - Why is this necessary, why can't each mix node detect this by itself? If they rely on a "PKI" for these parameters, doesn't the "PKI" hold some position of power over the network? - How do these parameters relate to the exponential/poisson RV parameters mentioned in the Loopix paper? Do those parameters also need to be uniform across all mix nodes? I suppose not, since it is supposed to defend against malicious mix nodes, but perhaps "most honest nodes" need to agree on the same parameters. In any case, I don't see the point being explained in great detail. (Again, this on a quick reading; I might have missed something.) Those are the specific questions. Apart from that, it would be good if you could summarise the differences between your design and Loopix plus some motivation on why. (Because people like me naturally ask "why not just do Loopix".) I gather that you do already talk about this elsewhere, it just would be nice to have it collected together in a separate document. For example the Loopix paper has a Section 6 "Related Work" and a Table 2 that summarises this - it was very nice to read that, especially for me who hasn't looked at this topic for a significant time. In particular, it would be good if you could talk a bit about how your differences, affect Loopix's original security properties. I think Section 2.3 "Security Goals" is quite a nice summary of what it's trying to achieve. If you could confirm that is indeed what your system is also aiming for, together with any other security properties it doesn't mention, it would be much easier to evaluate. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
