📅 Original date posted:2018-11-29 📝 Original message: Hi Corne, the HMACs are ...

Christian Decker [ARCHIVE] /

npub1wtx…tuyn

2023-06-09 12:53:14

in reply to nevent1q…4kxq

📅 Original date posted:2018-11-29
📝 Original message:
Hi Corne,

the HMACs are necessary in order to make sure that a hop cannot modify
the packet before forwarding, and the next node not detecting that
modification.

One potential attack that could facilitate is that an attacker could
learn the path length by messing with different per-hop payloads: set
n=0 the attacker flips bits in the nth per-hop payload, and forwards
it. If the next node doesn't return an error it was the final recipient,
if if returns an error, increment n and flip bits in the (n+1)th per-hop
payload, until no error is returned. Congratulation you just learned the
path length after you. The same can probably be done with the error
packet, meaning you can learn the exact position in the route. Add to
that the information you already know about the network (cltv_deltas,
amounts, fees, ...) and you can probably detect sender and recipient.

Adding HMACs solves this by ensuring that the next hop will return an
error if anything was changed, i.e., removing the leak about which node
would have failed the route.

Cheers,
Christian

Corné Plooy via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hi,
>
>
> Is there a reason why we have HMACs in Sphinx? What could go wrong if we
> didn't?
>
> A receiving node doesn't know anyway what the origin node is; I don't
> see any attack mode where an attacker wouldn't be able to generate a
> valid HMAC.
>
> A receiving node only knows which peer sent it a Sphinx packet;
> verification that this peer really sent this Sphinx packet is (I think)
> already done on a lower protocol layer.
>
>
> AFAICS, The only real use case of the HMAC value is the special case of
> a 0-valued HMAC, indicating the end of the route. But that's just silly:
> it's essentially a boolean, not any kind of cryptographic verification.
>
>
> CJP
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Author Public Key

npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn

Show more details

Published at

2023-06-09 12:53:14

Kind type

1 Short Text Note

Event JSON

{ "id": "b96edccbd093620497c5f477d633c83fef2cb8067e767cdda41cf1b67b323dda", "pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057", "created_at": 1686315194, "kind": 1, "tags": [ [ "e", "8655b319e5067135f1dc1e4f6a2deb0a8d8e5e4c09b5ffccfe961b3ca83e49c2", "", "root" ], [ "e", "28b42ee7f142ef332f90eb80ec968ef0813100fbcf16f3665518a8f67ee292eb", "", "reply" ], [ "p", "17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99" ] ], "content": "📅 Original date posted:2018-11-29\n📝 Original message:\nHi Corne,\n\nthe HMACs are necessary in order to make sure that a hop cannot modify\nthe packet before forwarding, and the next node not detecting that\nmodification.\n\nOne potential attack that could facilitate is that an attacker could\nlearn the path length by messing with different per-hop payloads: set\nn=0 the attacker flips bits in the nth per-hop payload, and forwards\nit. If the next node doesn't return an error it was the final recipient,\nif if returns an error, increment n and flip bits in the (n+1)th per-hop\npayload, until no error is returned. Congratulation you just learned the\npath length after you. The same can probably be done with the error\npacket, meaning you can learn the exact position in the route. Add to\nthat the information you already know about the network (cltv_deltas,\namounts, fees, ...) and you can probably detect sender and recipient.\n\nAdding HMACs solves this by ensuring that the next hop will return an\nerror if anything was changed, i.e., removing the leak about which node\nwould have failed the route.\n\nCheers,\nChristian\n\nCorné Plooy via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e writes:\n\u003e Hi,\n\u003e\n\u003e\n\u003e Is there a reason why we have HMACs in Sphinx? What could go wrong if we\n\u003e didn't?\n\u003e\n\u003e A receiving node doesn't know anyway what the origin node is; I don't\n\u003e see any attack mode where an attacker wouldn't be able to generate a\n\u003e valid HMAC.\n\u003e\n\u003e A receiving node only knows which peer sent it a Sphinx packet;\n\u003e verification that this peer really sent this Sphinx packet is (I think)\n\u003e already done on a lower protocol layer.\n\u003e\n\u003e\n\u003e AFAICS, The only real use case of the HMAC value is the special case of\n\u003e a 0-valued HMAC, indicating the end of the route. But that's just silly:\n\u003e it's essentially a boolean, not any kind of cryptographic verification.\n\u003e\n\u003e\n\u003e CJP\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev", "sig": "91f840639b9d823bc64cb78207f3cc3108b4b0c25fec221b93bd6dce93ce77730a22dce361dee0c7273196d754328168d9b050ddda2b5dcdd82d4f9e6a1caab4" }