📅 Original date posted:2016-10-20
📝 Original message:
> I kept the shared secret backlog for now, since committing the routing
> information to the payment hash is awkward
When we agreed to include the payment hash in the MAC check within the
header, I assumed that the packet format wouldn't be modified to include the
payment hash (either in the header or e2e payload).
Instead, I envisioned that the payment hash would be a parameter to the
packet processing/creation function. When creating or processing the packet,
the payment hash would be concatenated to the material being authenticated
similar to the "associated data" in AEAD cipher modes. With this scheme,
there's no additional data added to the packets, but the payment hash is
authenticated as part of packet processing at each hop.
So if an adversary attempts a replay, then they're forced to use the same
payment hash, otherwise the packet won't propagate. Assuming all nodes
remember all payment hashes, then replay attempts always fail and come at a
direct monetary cost to the attacker.
-- Laolu
On Thu, Oct 20, 2016 at 6:41 AM Christian Decker <decker.christian at gmail.com>
wrote:
> Just a quick update on my side: I have updated the spec as discussed
> during the milan meetup and dropped the end-to-end payload, since we don't
> have any good usecase for it currently.
>
> I kept the shared secret backlog for now, since committing the routing
> information to the payment hash is awkward: either we include the payment
> hash in each per-hop payload, making it possible to stop a replay
> immediately, or we add it to the last per-hop payload, at which point only
> the last hop would be able to identify a replay attack, making it possible
> to replay and observe traffic patterns. In both cases we'd be increasing
> the per-hop payload size, which is pretty expensive to do.
>
> Both the C-lightning implementation and the lnd implementations have been
> adapted and can be used.
>
> Cheers,
> Christian
>
>
> On Mon, Oct 3, 2016 at 11:34 PM Christian Decker <
> decker.christian at gmail.com> wrote:
>
> On Mon, Oct 03, 2016 at 05:21:35PM +0000, Olaoluwa Osuntokun wrote:
> > > I think this only works if the on-chain keys are Schnorr, right?
> >
> > We'd use the same curve equation and domain parameters as Bitcoin uses
> > currently, but would swap out EC-DSA for EC-Schnorr. So as a result,
> > pub/priv keys stay the same, meaning the on-chain keys can be used for
> > signing/verifying the multi-sign for channel authentication proofs.
>
> So we'd still be using ECDSA for everything that could go to the
> bitcoin blockchain, and use Schnorr for all other crypto
> primitives. Sounds good to me, if we can be certain that reuse across
> different schemes does not open us to new threats.
>
> > > Separating onion privkey allows rotation; only a win if we get forward
> > > secrecy (not a win for this node, as much as for the network as a
> > > whole).
> >
> > Agreed, if we're not initially doing passive (or active) key rotation for
> > the onion keys, then coupling the identity and onion keys simplifies the
> > code at that level and nixes a few network layer control messages.
>
> I'd argue that rotating the onion key is already valuable in order to
> limit the shared secret backlog, allowing us to forget them after a
> rotation, even if we don't have forward secrecy. If we can get forward
> secrecy as well all the better though :-)
>
> Cheers,
> Christian
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20161020/40137071/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:46:48
in reply to nevent1q…m28l
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:46:48Event JSON
{
"id": "8d897711311922d34414db087b8b4c9a4a42bdb7e10b1178ed6cd00626a6ef6b",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314808,
"kind": 1,
"tags": [
[
"e",
"6605b2ae81175dfc044ce5a6c3c8c35e7a388eb620fe0f1109d8c30c8b6896b3",
"",
"root"
],
[
"e",
"f50fadb79c19b898ca8d8a1ce2d10e31f753ef685c5ca921c8f7a58ce6f865dc",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2016-10-20\n📝 Original message:\n\u003e I kept the shared secret backlog for now, since committing the routing\n\u003e information to the payment hash is awkward\n\nWhen we agreed to include the payment hash in the MAC check within the\nheader, I assumed that the packet format wouldn't be modified to include the\npayment hash (either in the header or e2e payload).\n\nInstead, I envisioned that the payment hash would be a parameter to the\npacket processing/creation function. When creating or processing the packet,\nthe payment hash would be concatenated to the material being authenticated\nsimilar to the \"associated data\" in AEAD cipher modes. With this scheme,\nthere's no additional data added to the packets, but the payment hash is\nauthenticated as part of packet processing at each hop.\n\nSo if an adversary attempts a replay, then they're forced to use the same\npayment hash, otherwise the packet won't propagate. Assuming all nodes\nremember all payment hashes, then replay attempts always fail and come at a\ndirect monetary cost to the attacker.\n\n-- Laolu\n\n\nOn Thu, Oct 20, 2016 at 6:41 AM Christian Decker \u003cdecker.christian at gmail.com\u003e\nwrote:\n\n\u003e Just a quick update on my side: I have updated the spec as discussed\n\u003e during the milan meetup and dropped the end-to-end payload, since we don't\n\u003e have any good usecase for it currently.\n\u003e\n\u003e I kept the shared secret backlog for now, since committing the routing\n\u003e information to the payment hash is awkward: either we include the payment\n\u003e hash in each per-hop payload, making it possible to stop a replay\n\u003e immediately, or we add it to the last per-hop payload, at which point only\n\u003e the last hop would be able to identify a replay attack, making it possible\n\u003e to replay and observe traffic patterns. In both cases we'd be increasing\n\u003e the per-hop payload size, which is pretty expensive to do.\n\u003e\n\u003e Both the C-lightning implementation and the lnd implementations have been\n\u003e adapted and can be used.\n\u003e\n\u003e Cheers,\n\u003e Christian\n\u003e\n\u003e\n\u003e On Mon, Oct 3, 2016 at 11:34 PM Christian Decker \u003c\n\u003e decker.christian at gmail.com\u003e wrote:\n\u003e\n\u003e On Mon, Oct 03, 2016 at 05:21:35PM +0000, Olaoluwa Osuntokun wrote:\n\u003e \u003e \u003e I think this only works if the on-chain keys are Schnorr, right?\n\u003e \u003e\n\u003e \u003e We'd use the same curve equation and domain parameters as Bitcoin uses\n\u003e \u003e currently, but would swap out EC-DSA for EC-Schnorr. So as a result,\n\u003e \u003e pub/priv keys stay the same, meaning the on-chain keys can be used for\n\u003e \u003e signing/verifying the multi-sign for channel authentication proofs.\n\u003e\n\u003e So we'd still be using ECDSA for everything that could go to the\n\u003e bitcoin blockchain, and use Schnorr for all other crypto\n\u003e primitives. Sounds good to me, if we can be certain that reuse across\n\u003e different schemes does not open us to new threats.\n\u003e\n\u003e \u003e \u003e Separating onion privkey allows rotation; only a win if we get forward\n\u003e \u003e \u003e secrecy (not a win for this node, as much as for the network as a\n\u003e \u003e \u003e whole).\n\u003e \u003e\n\u003e \u003e Agreed, if we're not initially doing passive (or active) key rotation for\n\u003e \u003e the onion keys, then coupling the identity and onion keys simplifies the\n\u003e \u003e code at that level and nixes a few network layer control messages.\n\u003e\n\u003e I'd argue that rotating the onion key is already valuable in order to\n\u003e limit the shared secret backlog, allowing us to forget them after a\n\u003e rotation, even if we don't have forward secrecy. If we can get forward\n\u003e secrecy as well all the better though :-)\n\u003e\n\u003e Cheers,\n\u003e Christian\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20161020/40137071/attachment.html\u003e",
"sig": "5614721557e558404047aacd819a943679bd17e4038ca37f7618807e3c38687e06cb1f370a5e2578d8ac51aa532747cb7ef00c5419525460a695370c25c7c9d4"
}