What is Nostr?
Anthony Towns [ARCHIVE] /
npub17rl…9l2h
2023-06-09 12:44:25
in reply to nevent1q…rela

Anthony Towns [ARCHIVE] on Nostr: πŸ“… Original date posted:2015-09-22 πŸ“ Original message: On Tue, Sep 22, 2015 at ...

πŸ“… Original date posted:2015-09-22
πŸ“ Original message:
On Tue, Sep 22, 2015 at 11:22:57AM +1000, Anthony Towns wrote:
> If you use OFB or CTR mode for the symmetric cypher, you can calculate
> D_KD() of all the padding and use that to work out the hash H of the
> plaintex message:
> here's $15
> grbg grbg ... grbg
> D_KD(
> D_KC( D_KB( E_KA( 0000 ) ) )
> D_KC( E_KB( 0000 ) )
> E_KC( 0000 )
> )

On Mon, Sep 21, 2015 at 06:18:37AM +0930, Rusty Russell wrote:
> > For a general solution, I think you could completely rule out probing
> > by having two R values, one known only by the recipient, and one by
> > the sender (call it S say). Then make the htlcs payable on
> > presentation of both R and S and include S encrypted to the final
> > recipient in the onion payload. Munging the payload then makes the
> > htlc irredeemable so misrouting it gives no information.
> That's clever. And I think it works.

You could combine these two approaches actually. If X is the plaintext
routing message the payee gets ("here's $15 grbg grbg ..."), and H is
its hash that was prefixed to the plaintext, then set S=sha256(H+X),
and require revealing S as well as R for payment redemption (ie, include
"OP_SHA256 sha256(S) OP_EQ" in the HTLC).

That way *any* attempt to garble the padding makes S unrecoverable
and renders the payment unredeemable, without relying on any
verification/cooperation from anyone else on the network.

Cheers,
aj
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h