[messaging] Panoramix decryption mixnet messaging spec and design documents

[dawuud]

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.

> It's true, cross over points and SURBs add complexity to the
> implementation, and make the header larger, but actually they do not
> complicate the fields of the packet format.  In particular, the cross
> over point should extract the SURB from beta, not some separate SURB
> field or delta. 
> https://github.com/burdges/lake/blob/master/Xolotl/papers/Xolotl-2-sphinx.tex#L150-L180

Yes, for your use case this makes sense and for Katzenpost we've taken
a different approach. For those of you following along who haven't
read the Sphinx paper, by delta Jeff means the Sphinx packet
payload. And by beta he means "routing info" section of the header. In
our Sphinx spec we use descriptive names instead of Greek symbols:

https://github.com/Katzenpost/docs/blob/f45fa33a747fe908090756446259f7b67e543731/specs/sphinx.txt#L283

> In fact, SURBs do not complicate the implementation much either.
> Actually using SURBs does require a delicate strategy for distributing
> the SURBs though.  *That* is the real complexity.

Sure but it depends on how the SURBs are used. Our Katzenpost design
uses SURBs in a *very* simple manner. Our usage of Sphinx terminates
at the destination Provider, the payload contains two items:

1. a SURB for sending an ACKnowledgement message
2. end to end Noise_X ciphertext to be queued for later retrieval

It sounds like your usage of SURBs allows for some identity-hiding properties
such as:

* sender anonymity
* receiver anonymity

These are properties I would want in future mixnet messaging systems.

> Anyways, there is no reason a mix network must commit to using SURBs or
> not.  It should design the packet format to support SURBs regardless,
> and ideally even do cross over points, but may initially avoid the
> complexity of distributing SURBs.

I disagree with these two points. Firstly, SURB usage increases
exposure to compulsion attacks, which is a reason not to use them but
this reason may not be sufficiently established for all use cases.

Secondly, it is not necessary for all decryption mixnets to support
SURBs and cross over points. I think it really depends on the
application. My counter example was briefly mentioned in my previous
e-mail where a decryption mixnet is used as a transport for zcash
transactions. In this case, we can get away with a very simple design
where only forward messages are utilized.  The blockchain can later be
examined to determine if a retransmission is needed.

OK... but I admittedly cannot think of other applications with a similar
broadcast mechanism.

> On Sat, 2017-09-16 at 22:21 +0000, 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 only use SURBs to send ACKnowledgements in
> > our Stop and Wait ARQ protocol from Client to Provider.
> 
> I'm sure I've pointed this out to you guys before, David, but ACKs do
> not need SURBs per se.  At least not if the ACK comes from the mail
> server as opposed to the user.  You just send a packet in a loop, but

Indeed! I think this is an excellent idea AND I think we should make a
note of all the different ways we can think of to send ACKs in mixnet
designs because each of them is going to have differing tradeoffs. For
instance, how big is your Sphinx header when stuffing SURBs into the
"routing info" section?  Do you force all "routing info" slots per hop
to be the same size?  Actually, it sounds like you've got a great many
variations to work with and that a chart to show features versus
overhead sizes might be helpful.

...and by "mail server" you mean "Provider" in the Loopix terminology.
I'm very pleased that our current design avoids running any mail servers.
We queue messages on the Providers. Similar but better. No SMTP!

> execute a special command mid way that drops off the message and
> replaces it with the ACK.  It only requires that packet building split
> 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. 

The Sphinx packet format is so flexible, I think it's great that you
are exploring various ways it can be used and thinking about
reliability.  I suspect most humans will not want to use an unreliable
crypto messaging system.


Regards,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20170917/ccaee97f/attachment.sig>