[messaging] Panoramix decryption mixnet messaging spec and design documents

[Trevor Perrin]

On Wed, Aug 9, 2017 at 2:53 AM, dawuud <dawuud at riseup.net> 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

[...]

> https://github.com/Katzenpost/docs/blob/master/drafts/mixdesign.txt

[...]

> https://github.com/Katzenpost/docs/blob/master/drafts/user_interface.txt



Hi David,

Hope you don't mind belated comments:

This is an ambitious protocol stack!  I think the different layers and
choices are something like:

Mix packet format = Sphinx
Mix strategy = Poisson Mix (a simplified "Stop-and-Go Mix")
Mixnet topology = Stratified
Dummy traffic strategy = Loopix
Reliability/retransmission = Stop-and-Wait ARQ
Congestion control = "Source Quench" from mixes to providers
Link protocol = TCP/Noise_XX
End-to-end protocol = Email/Noise_X

It's interesting to see everything needed for a full mixnet architecture.
I imagine these decisions might be different for different applications, so
I hope you're building modularity between components.

"Sphinx" and "Stop-and-Go mixes" seem particularly reusable within
different architectures.  High-quality specs and code for them would be one
great outcome here.

(Though there's room for debate even within those components.  For example,
SURB support in Sphinx adds complexity and requires an unusual
"large-block" cipher.  SURBs don't seem necessary for Loopix, and I've
wondered whether dropping SURB support would make things simpler [1])

Anyways, the hardest decisions are probably around "mixnet topology" and
"dummy traffic", since this is where real-world economic and deployability
concerns come in:
 * Who is going to run mixes?
 * How tolerable are latency and dummy-traffic requirements for real users?

The Loopix paper [2] presents examples with:
 * Several independent mix nodes
 * A server acting as "provider" for each few hundred users
 * Each user sending a dummy message every few seconds (or faster!)
 * Each user downloading messages or dummy traffic from their provider at a
constant rate

Those all seem like difficult requirements for real systems, so I'm
wondering about your thoughts on near-term deployment.

In general, the security vs. practicality tradeoffs seem pretty brutal for
mixnets.  Most papers (like Loopix) push the slider towards the security
end so they can achieve their security goal, but with parameters unlikely
to be deployed at any scale.  I'd be more interested in the opposite sort
of analysis: how much security can be eked out of "minimum viable"
deployments.

Anyways, those are scattered thoughts.  It's great to see people working in
this area, keep us posted!

Trevor

[1]
https://moderncrypto.org/mail-archive/messaging/2014/000456.html
https://moderncrypto.org/mail-archive/messaging/2014/000471.html

[2] https://arxiv.org/pdf/1703.00536.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20170916/baa17e09/attachment.html>