Published on: 2015-09-22T10:38:08+00:00
Zooko Wilcox-OHearn requested notes about the requirements/desiderata for a source routing network, and Rusty provided the necessary information. The network works on an onion routing-style setup where each node only knows the previous and next nodes for financial privacy reasons. Rusty is working on test code that includes one node hop and a full route description in the onion structure. The receiving node uses ECDH to extract the secret key and derives encryption keys, HMAC keys, and initialization vectors. After verifying the HMAC and decrypting the onion structure, the first struct hop is forwarded and padding is added to maintain the total length. Unused hops are filled with random garbage.In the email exchange, Anthony Towns suggests using OFB or CTR mode for the symmetric cipher. Rusty proposes a method involving two R values, known by the recipient and sender, respectively. Including S encrypted to the final recipient in the onion payload makes misrouting the HTLC irredeemable. Anthony suggests combining both approaches and reveals that S should be sha256(H+X), where X is the plaintext routing message and H is its hash. Revealing both S and R is required for payment redemption. This combined approach ensures that attempts to garble the padding render the payment unredeemable without relying on verification from others on the network.Rusty explains the format of a route for onion routing, including required bytes of data decrypted by each node using their pubkey. The route is created backward to calculate the size and randomly picks a total size between 1024 and 4096, padding it with at least 32 bytes of random padding. Probing the route to guess the final destination is possible, but there is no general fix for this issue. To prevent errors from leaking information, signing errors and using the 'sum' field as a secret key is suggested. However, onion routing only provides limited protection against correlating HTLCs by R value.The email conversation between Rusty Russell and Anthony Towns discusses the vulnerability of Tor to probing attacks that reveal the length of the chain. Adding random bytes or letting nodes add padding introduces probing attacks where corrupted packets can still succeed. Rusty suggests including a pubkey and encrypting 0 padding to address this problem. However, the solution is missing a step in generating symmetric keys for each step in an onion route. It is suggested that the format of a route should include required bytes hop_key encrypted with the public key and required bytes route encrypted with hop_key.Rusty discusses methods to protect transaction routes from being guessed and exploited. Nodes create the route backward, calculate its size, randomly pick a total size, and pad it with random bytes. Storing the expected balance to be forwarded rather than the fee allows the next node to abort the transaction if someone takes too much. Re-padding the onion blob when forwarding prevents it from revealing the end of the chain. Including a pubkey and using it to encrypt 0 padding is suggested. Rusty acknowledges that flaws or simplifications may be present in his suggestions due to lack of coffee.In a thread on the Lightning Network mailing list, Rusty Russell discusses the weakness of the network's security against route probing attacks. Without a MAC, nodes can replace routing entirely and probe by guessing the final destination right. He believes there is no general fix for this issue. Parallel probes and probabilistic backoff have limitations, and surveillance through cheap hubs is considered unlikely to scale. To rule out probing, Rusty suggests having two R values known by the recipient and sender, making HTLCs payable on presentation of both R and S. The combined approach makes misrouting HTLCs irredeemable.Rusty shares code for creating a route backward and calculating its size. The total size is randomly picked between 1024 and 4096 and padded with random bytes. This offers protection against guessing the route length. Suggestions are made to store the expected balance instead of the fee and to re-pad the onion blob when forwarding. Rusty admits that flaws or simplifications may be present due to lack of coffee.In an email conversation, Rusty Russell discusses the possibility of Route Probing Attacks on the R values of HTLCs in the Lightning Network. Without a MAC, nodes can replace routing entirely and probe by guessing the final destination right. One defense is to fail two HTLCs with the same R value, but this enables probing back to the source. Parallel probes have limitations, and probing may not be plausible on a mass scale. Having two R values known only by the recipient and sender could completely rule out probing. Munging the payload makes misrouted HTLCs irredeemable.
Updated on: 2023-07-31T18:18:52.884541+00:00