📅 Original date posted:2016-10-03
📝 Original message:
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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:46:48
in reply to nevent1q…2v2y
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:46:48Event JSON
{
"id": "50aae1042908bb545d138e0a04713cbdd9acaf433100d1564dae22193af0f533",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314808,
"kind": 1,
"tags": [
[
"e",
"6605b2ae81175dfc044ce5a6c3c8c35e7a388eb620fe0f1109d8c30c8b6896b3",
"",
"root"
],
[
"e",
"5a1f63443074407542322c8a145e8d2300fecd8f60806be8f9412d8d64124010",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2016-10-03\n📝 Original message:\nOn Mon, Oct 03, 2016 at 05:21:35PM +0000, Olaoluwa Osuntokun wrote:\n\u003e \u003e I think this only works if the on-chain keys are Schnorr, right?\n\u003e \n\u003e We'd use the same curve equation and domain parameters as Bitcoin uses\n\u003e currently, but would swap out EC-DSA for EC-Schnorr. So as a result,\n\u003e pub/priv keys stay the same, meaning the on-chain keys can be used for\n\u003e signing/verifying the multi-sign for channel authentication proofs.\n\nSo we'd still be using ECDSA for everything that could go to the\nbitcoin blockchain, and use Schnorr for all other crypto\nprimitives. Sounds good to me, if we can be certain that reuse across\ndifferent schemes does not open us to new threats.\n\n\u003e \u003e Separating onion privkey allows rotation; only a win if we get forward\n\u003e \u003e secrecy (not a win for this node, as much as for the network as a\n\u003e \u003e whole).\n\u003e \n\u003e Agreed, if we're not initially doing passive (or active) key rotation for\n\u003e the onion keys, then coupling the identity and onion keys simplifies the\n\u003e code at that level and nixes a few network layer control messages.\n\nI'd argue that rotating the onion key is already valuable in order to\nlimit the shared secret backlog, allowing us to forget them after a\nrotation, even if we don't have forward secrecy. If we can get forward\nsecrecy as well all the better though :-)\n\nCheers,\nChristian",
"sig": "bbd923b0eab7ef5e017e65f0ab24e97181216f7d45ca9f90ff959a9f60e1564d29648af1d77eec5d023f434065d413f24e84c28471d9abf88044a7cdb54d5abe"
}