[messaging] Panoramix decryption mixnet messaging spec and design documents
burdges at gnunet.org
Sat Sep 16 19:39:27 PDT 2017
I've an unfinished document that analyzes different forms the Sphinx
packet format might take :
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.
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.
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.
As an aside, if you want to be worried, you should check out my SURB log
It's stream cipher encrypted and unMACed! It should be secure for the
limited purpose which it serves though.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Messaging