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
π 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