Joseph Poon [ARCHIVE] on Nostr: š Original date posted:2016-08-09 š Original message: Hi Rusty, On Tue, Aug 09, ...
š
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
š 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