📅 Original date posted:2016-08-09
📝 Original message:
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:
1. Take the txid and use two salts (globally for all users).
HMAC(txid+salt1) and HMAC(txid+salt2). Give the result of
HMAC(txid+salt1) and the encrypted blob to the outsourcer. The first is
used for identifying the txid, the second salt is for the secret key and
can only be derived when the actual txid is seen. When a transaction is
received, do HMAC(txid+salt1) and see if there's any matches to decrypt
& broadcast.
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.
I do like encrypting the outsourcing blobs best as an approach so far,
as it gives maximum flexibility in terms of implementation (individual
client behavior can be upgraded in the future without modifying the
outsourcing code/nodes in most instances).
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:46:34
in reply to nevent1q…3jlg
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:46:34Event JSON
{
"id": "07dab668deb7d0378e4248ce732eb6e178af281072eaa57371c9b8980029ddba",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314794,
"kind": 1,
"tags": [
[
"e",
"ccc2d459792b926854b04bc74e6ea324d2314fff88991806647cc195016ae9ae",
"",
"root"
],
[
"e",
"3346b0cd0b0138287ab668b4a443431ffac928ea8f19ad96aa52155a573cc8ff",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-08-09\n📝 Original message:\nHi Rusty,\n\nOn Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote:\n\u003e We send the observer the \"steal\" tx every update (not really: we only\n\u003e need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).\n\u003e This gets encrypted+HMAC with the txid of the commit tx (or, if that's\n\u003e too guessable, the SHA256() of our signature on the commit tx).\n\u003e\n\u003e [snip]\n\u003e\n\u003e If we want to obscure our funding tx, we can simply use a txid qualifier\n\u003e the same way you did (and maybe use the sha256(txid) as the encryption\n\u003e key to avoid weakening that).\n\nI think it may be necessary to identify when the transaction occurs as\nan index for outsourcing services, so the key can't be dervied directly\nfrom the txid with a single HMAC/sha256. It's possible there are\nmillions of transactions to compare, and an index based on txid is\nnecessary. The two options I can see are:\n\n1. Take the txid and use two salts (globally for all users).\nHMAC(txid+salt1) and HMAC(txid+salt2). Give the result of\nHMAC(txid+salt1) and the encrypted blob to the outsourcer. The first is\nused for identifying the txid, the second salt is for the secret key and\ncan only be derived when the actual txid is seen. When a transaction is\nreceived, do HMAC(txid+salt1) and see if there's any matches to decrypt\n\u0026 broadcast.\n\n2. HMAC the transaction itself (not txid) as the secret key (or anything\npart of the transaction, as long as it isn't SHA256(tx) for obvious\nreasons). I like something along these lines better than option #1.\nWhatever computational cost there is will be extremely low, as the\noperations are constrained by block size.\n\nI do like encrypting the outsourcing blobs best as an approach so far,\nas it gives maximum flexibility in terms of implementation (individual\nclient behavior can be upgraded in the future without modifying the\noutsourcing code/nodes in most instances).\n\n-- \nJoseph Poon",
"sig": "7b95a1c119c3034e5203bf7b7e3d1c2636c204b97eafc814862aa0f86b4836c0e49acc35827b21076beb1bdaff000f2bf0524f420ccdd3256e34f458ca07caf6"
}