📅 Original date posted:2016-08-09
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> On Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote:
>> We send the observer the "steal" tx every update (not really: we only
>> need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
>> This gets encrypted+HMAC with the txid of the commit tx (or, if that's
>> too guessable, the SHA256() of our signature on the commit tx).
>>
>> [snip]
>>
>> If we want to obscure our funding tx, we can simply use a txid qualifier
>> the same way you did (and maybe use the sha256(txid) as the encryption
>> key to avoid weakening that).
>
> I think it may be necessary to identify when the transaction occurs as
> an index for outsourcing services, so the key can't be dervied directly
> from the txid with a single HMAC/sha256. It's possible there are
> millions of transactions to compare, and an index based on txid is
> necessary. The two options I can see are:
This is fun!
Yes, I think we agree some "filter hint" is needed to avoid a crazy
amount of outsourcing work (eg. first 8/16 bytes of txid). I don't
think an HMAC check per registered commitment is quite fast enough.
But there's a problem with most naive filters, if you can guess
commitment tx N-1 from commitment tx N. If the outsourcing service sees
an old commit they can guess at previous commitment txs using that.
Probably unroll the whole channel history if they can guess enough
HTLCs.
> 2. HMAC the transaction itself (not txid) as the secret key (or anything
> part of the transaction, as long as it isn't SHA256(tx) for obvious
> reasons). I like something along these lines better than option #1.
> Whatever computational cost there is will be extremely low, as the
> operations are constrained by block size.
If we include the witness in that HMAC we risk reintroducing
malleability. If we don't, we risk txs being predictable.
I can think of a few fixes: insert some randomness in the tx (OP_RETURN?
Different addresses each time?), or try to extract the input signature
from the witness, which is unguessable, as our filter?
What's simplest?
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 14:46:34
in reply to nevent1q…wu7d
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 14:46:34Event JSON
{
"id": "b64cee7dff912638a4c186bbb2ce59e37eba200e1460782b4b78490b843c52d1",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314794,
"kind": 1,
"tags": [
[
"e",
"ccc2d459792b926854b04bc74e6ea324d2314fff88991806647cc195016ae9ae",
"",
"root"
],
[
"e",
"07dab668deb7d0378e4248ce732eb6e178af281072eaa57371c9b8980029ddba",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2016-08-09\n📝 Original message:\nJoseph Poon \u003cjoseph at lightning.network\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e On Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote:\n\u003e\u003e We send the observer the \"steal\" tx every update (not really: we only\n\u003e\u003e need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).\n\u003e\u003e This gets encrypted+HMAC with the txid of the commit tx (or, if that's\n\u003e\u003e too guessable, the SHA256() of our signature on the commit tx).\n\u003e\u003e\n\u003e\u003e [snip]\n\u003e\u003e\n\u003e\u003e If we want to obscure our funding tx, we can simply use a txid qualifier\n\u003e\u003e the same way you did (and maybe use the sha256(txid) as the encryption\n\u003e\u003e key to avoid weakening that).\n\u003e\n\u003e I think it may be necessary to identify when the transaction occurs as\n\u003e an index for outsourcing services, so the key can't be dervied directly\n\u003e from the txid with a single HMAC/sha256. It's possible there are\n\u003e millions of transactions to compare, and an index based on txid is\n\u003e necessary. The two options I can see are:\n\nThis is fun!\n\nYes, I think we agree some \"filter hint\" is needed to avoid a crazy\namount of outsourcing work (eg. first 8/16 bytes of txid). I don't\nthink an HMAC check per registered commitment is quite fast enough.\n\nBut there's a problem with most naive filters, if you can guess\ncommitment tx N-1 from commitment tx N. If the outsourcing service sees\nan old commit they can guess at previous commitment txs using that.\nProbably unroll the whole channel history if they can guess enough\nHTLCs.\n\n\u003e 2. HMAC the transaction itself (not txid) as the secret key (or anything\n\u003e part of the transaction, as long as it isn't SHA256(tx) for obvious\n\u003e reasons). I like something along these lines better than option #1.\n\u003e Whatever computational cost there is will be extremely low, as the\n\u003e operations are constrained by block size.\n\nIf we include the witness in that HMAC we risk reintroducing\nmalleability. If we don't, we risk txs being predictable.\n\nI can think of a few fixes: insert some randomness in the tx (OP_RETURN?\nDifferent addresses each time?), or try to extract the input signature\nfrom the witness, which is unguessable, as our filter?\n\nWhat's simplest?\nRusty.",
"sig": "cf713c2b8414172362fecc9875141c8d3c06925419f5595887dc5611d8db862505909503b6b15204f9064bab345c4ab12791fd3f56e7c06bcfd95b7d5e663f8f"
}