📅 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
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:25
in reply to nevent1q…rela
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:25Event JSON
{
"id": "f0b4ca34128bfbdd9d9d882954f794c8143ea51c9c067e1b962e54c3e39468b2",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314665,
"kind": 1,
"tags": [
[
"e",
"36906e9db439c1be0c33c07064c5914ca50c01ffdfa370a0d6a3e54356187808",
"",
"root"
],
[
"e",
"667c6b8bd5e134ac287da8dbd2f8adff2baa882449d49ed0914b32c539b53a75",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-22\n📝 Original message:\nOn Tue, Sep 22, 2015 at 11:22:57AM +1000, Anthony Towns wrote:\n\u003e If you use OFB or CTR mode for the symmetric cypher, you can calculate\n\u003e D_KD() of all the padding and use that to work out the hash H of the\n\u003e plaintex message:\n\u003e here's $15\n\u003e grbg grbg ... grbg\n\u003e D_KD(\n\u003e D_KC( D_KB( E_KA( 0000 ) ) )\n\u003e D_KC( E_KB( 0000 ) )\n\u003e E_KC( 0000 )\n\u003e )\n\nOn Mon, Sep 21, 2015 at 06:18:37AM +0930, Rusty Russell wrote:\n\u003e \u003e For a general solution, I think you could completely rule out probing\n\u003e \u003e by having two R values, one known only by the recipient, and one by\n\u003e \u003e the sender (call it S say). Then make the htlcs payable on\n\u003e \u003e presentation of both R and S and include S encrypted to the final\n\u003e \u003e recipient in the onion payload. Munging the payload then makes the\n\u003e \u003e htlc irredeemable so misrouting it gives no information.\n\u003e That's clever. And I think it works.\n\nYou could combine these two approaches actually. If X is the plaintext\nrouting message the payee gets (\"here's $15 grbg grbg ...\"), and H is\nits hash that was prefixed to the plaintext, then set S=sha256(H+X),\nand require revealing S as well as R for payment redemption (ie, include\n\"OP_SHA256 sha256(S) OP_EQ\" in the HTLC).\n\nThat way *any* attempt to garble the padding makes S unrecoverable\nand renders the payment unredeemable, without relying on any\nverification/cooperation from anyone else on the network.\n\nCheers,\naj",
"sig": "a74d759efbc91cd01e169f5fce26e18fcc80f7538e4cc196913160ff91c156ba9a156552857a4836faca58026196d042ecb22ebfb41a0a3361bd1adba67e3ef7"
}