Fix the SphinxPacket constructor wrt delays

[jstuczyn]

When making a sphinx packet you are required to pass as many delays as there are nodes in the provided route. However, the final hop is not going to be delaying anything. The final value is not even used in the library. So let's fix that, shall we?

[burdges]

Ideally, you should not pass any delays but instead they should be derived deterministically from the key exchange. This reduces the client's control over the delays, which sounds desirable. And it's less code than passing around delays. I mentioned this to Anya at Eurocrypt over a year ago.

[aniampio]

@burdges The packets in Nym mixnet are source-routed, meaning that the sender picks both the path and the individual delays for each mix hop. We want the sender to pick the delays since we want the sender to know how long the packet is kept at each mix node since this helps a lot with the relability (the sender can estimate when he should receive the ACK). The delays are picked from the exponential distribution with parameter lambda (this lambda is the expected value of the exponential distribution). At Nym, we do not use a single lambda (as we did in Loopix) but instead, we give clients a set of possible lambdas to use (note, all clients have the same set of possible lambdas to choose from). This is very usefull given that Nym wants to support a large range of applications, from the latency-sensitive ones, to the ones which are latency-tolerant.
What you described sounds interesting, but I'm not sure it is possible, since:

• we want the senders to have control over the delays (i.e., the sender should know the delay at each mix hop),
• given the fact that there is no single lambda, but a set of possible lambdas, how would a mix know which lambda it should feed into the exponencial distribution to sample the delay? We would have to pass some information about which lambda should be used within the Sphinx packet, which I think is no better than just passing the actual delay?
  Happy to hear your feedback on that! :)

[burdges]

It's clear the sender knows the delays in what I suggested since they know all the key exchange results.

It's odd to have multiple lambdas of course, but.. If you've multiple lambdas, and these are not associated with other visible packet metadata like payload size, then yes the sender should just specify the delay explicitly in the packet. Anything they'd say about lambda leaks more information than simply giving the delay sampled from Exp(lambda). Fair enough.. :)