š
Original date posted:2016-03-02
š Original message:
Just discovered that it is possible to attack the onion routing with
probing too short of an absolute CLTV refund timeout.
When accepting a payment, one will check if the remaining timeout >
MIN_TIMEOUT.
When relaying the payment to the next node, one can either decide to
check directly if the next node would accept it, or just relay and see
what happens (the next node would then refuse to include the payment).
Checking directly is equivalent of checking for 2 * MIN_TIMEOUT before
accepting it. However, as the next node will check for 2 * MIN_TIMEOUT
again, this is running in circles and just blindly increasing the final
MIN_TIMEOUT.
For an attacker it is now possible to choose a timeout that is lower
than 2 * MIN_TIMEOUT. If the payment succeeds, he knows that the next
node was the final receiver, if it doesn't he can redo the payment with
a larger timeout without any drawback, basically probing all payments once.
As discussed above, testing for a larger timeout before accepting /
relaying does not solve this problem. If all nodes only accept payments
with timeout > 10 * MIN_TIMEOUT, you can still probe with 10.5 *
MIN_TIMEOUT.
I think the only way to solve this would be to include
(1) the timeout the previous node should have sent you
(2) the timeout you should use for the next node
into the onion object and test it accordingly.
If you discover that the previous node messed with the timeout, you
directly refund it. It further complicates routing though, as the source
of the payment needs to know all MIN_TIMEOUT of the nodes in the route.
It also needs more coordination when doing RP-routing, as the receiver
has to include the timeout he chose for the first hop of his route.
It probably also opens up another attack vector for attacking the
network with unroutable payments.
Cheers
--
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160302/06cb6a52/attachment.sig>;
Mats Jerratsch [ARCHIVE] /
npub1hzā¦q5x8w
2023-06-09 12:45:47
in reply to nevent1qā¦w3ls
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:45:47Event JSON
{
"id": "0d0fd11c5b2699e90104ce2f472a94ad90ff765cf5470765dfdd9b86b5de0c92",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314747,
"kind": 1,
"tags": [
[
"e",
"5272205def020e3c5aab3c5851dc225814c5007aed79816e637c6362b3942e81",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2016-03-02\nš Original message:\nJust discovered that it is possible to attack the onion routing with\nprobing too short of an absolute CLTV refund timeout.\n\nWhen accepting a payment, one will check if the remaining timeout \u003e\nMIN_TIMEOUT.\n\nWhen relaying the payment to the next node, one can either decide to\ncheck directly if the next node would accept it, or just relay and see\nwhat happens (the next node would then refuse to include the payment).\n\nChecking directly is equivalent of checking for 2 * MIN_TIMEOUT before\naccepting it. However, as the next node will check for 2 * MIN_TIMEOUT\nagain, this is running in circles and just blindly increasing the final\nMIN_TIMEOUT.\n\nFor an attacker it is now possible to choose a timeout that is lower\nthan 2 * MIN_TIMEOUT. If the payment succeeds, he knows that the next\nnode was the final receiver, if it doesn't he can redo the payment with\na larger timeout without any drawback, basically probing all payments once.\n\nAs discussed above, testing for a larger timeout before accepting /\nrelaying does not solve this problem. If all nodes only accept payments\nwith timeout \u003e 10 * MIN_TIMEOUT, you can still probe with 10.5 *\nMIN_TIMEOUT.\n\nI think the only way to solve this would be to include\n(1) the timeout the previous node should have sent you\n(2) the timeout you should use for the next node\ninto the onion object and test it accordingly.\n\nIf you discover that the previous node messed with the timeout, you\ndirectly refund it. It further complicates routing though, as the source\nof the payment needs to know all MIN_TIMEOUT of the nodes in the route.\nIt also needs more coordination when doing RP-routing, as the receiver\nhas to include the timeout he chose for the first hop of his route.\n\nIt probably also opens up another attack vector for attacking the\nnetwork with unroutable payments.\n\n\nCheers\n-- \nMats Jerratsch\nBackend Engineer, Blockchain\ne: mats.jerratsch at blockchain.com\nPGP: https://pgp.mit.edu/pks/lookup?op=get\u0026search=0x7F3EC6CA\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160302/06cb6a52/attachment.sig\u003e",
"sig": "aab267842cfd94ba7d154e390b0feacca03646e406287149f428b7a1471c1d00c43aa9683ba0522a741bcbd7011593377e66fb562f7a3bfc03b1582d38a18aa3"
}