lightningnetwork / lightning-onion Goto Github PK

Issue

Within the network, it's important that when an HTLC forwarding failure occurs, the recipient is notified in a timely manner in order to ensure that errors are graceful and not unknown. However, we also want to ensure the privacy of the onion routing scheme, meaning that the intermediate hops don't know the exact location of the initiating sender. Therefore, nodes need to use the existing circuit to report the error with a message traveling backwards from the point of error to the original sender.

Within the current spec draft the handling of the scenario described above is detailed in sufficiently in the returning messages section.

This error wrapping and decryption at the sender is currently unimplemented.

Steps to Completion

• The ProcessPacket method should also return an object which encapsulates the derived shared secret, and provides a method/function to create a wrapped error messages.

• Similarly, the NewOnionPacket function should return a similar object which encapsulates the derived shared secret, and the encoded route. The object should provide a method/function to perform trial decryption (O(N^2) work, since we don't know which node in the route send the message).

I do not know if your use of the Sphinx packet format is such that variable length routes are used... however you should know that your Sphinx packet implementation does leak the route length to the last hop.

According to the recently submitted paper: Breaking and (Partially) Fixing Provably Secure Onion Routing, ( https://arxiv.org/abs/1910.13772 ) there is a padding bug where a sphinx implementation creates a header and in so doing uses zeros to pad the beta field whereas random data should be used instead because of the use of the stream cipher...

https://github.com/UCL-InfoSec/sphinx/blob/c05b7034eaffd8f98454e0619b0b1548a9fa0f42/SphinxClient.py#L67

# The os.urandom used to be a string of 0x00 bytes, but that's wrong
beta = dest + id + os.urandom(((2 * (p.r - nu) + 2)*p.k - len(dest)))
beta = p.xor(beta,
p.rho(p.hrho(asbtuples[nu-1]['s']))[:(2*(p.r-nu)+3)*p.k]) + phi

This bug, that is, if beta were padded with zeros instead of random bytes would allow
an adversary to determine the length of the route. This adversary would have to be the last hop and it could then XOR the beta portion of the header with zero bytes to learn how many skipped hops the Sphinx packet had.

Hi Roastbeef,

Although in the original paper is not expected, IMHO it would be appropriate to add a byte at the beginning of Common header to be used to versioning the Hornet protocol (as indeed exists in the IP protocol). My proposal is:

Andrea

If there is a topology, say, A-B-C, and A want to send a transaction to C via this route.
However, the channel from B to C does not have sufficient capacity, from the wiki, we know that there will be a temporary_channel_failure error msg responsed.

Then the question is: Will the HTLC contract between A and B be cancelled before the timeout of this HTLC?

hey, nice work with ln and this module!

at hashmatter we're planning to implement the sphinx-onion and hornet message formats and protocols for general purpose, to be used as a privacy preserving primitive. it would be very helpful not to have to implement everything from the bottom up. since this module looks like the best golang implementation of sphinx, have you considered to refactor this module at any point for general purpose?

also, what are the goals in terms of implementing HORNET? again, it would be great to have a general purpose module that could be used by any project. I'm sure there are other project-related priorities, but I believe we could help with that.

the nonce isn't set!?
https://github.com/lightningnetwork/lightning-onion/blob/master/sphinx.go#L337-L338

perhaps you could argue that setting the nonce isn't strictly necessary?