From aj at erisian.com.au  Tue Sep 22 05:25:44 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Tue, 22 Sep 2015 15:25:44 +1000
Subject: [Lightning-dev] Onion routing design.
In-Reply-To: <87twqohl5m.fsf@rustcorp.com.au>
 <20150922012257.GA22782@navy>
Message-ID: <20150922052544.GA29356@navy>

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