From decker.christian at gmail.com  Fri Oct 21 08:30:59 2016
From: decker.christian at gmail.com (Christian Decker)
Date: Fri, 21 Oct 2016 10:30:59 +0200
Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec
In-Reply-To: <CAO3Pvs8hzNicDryzS0K2Cg5ACx+f0p2mdPXckLzmrhQQ0xk55w@mail.gmail.com>
References: <20160902120822.GA4575@nex> <87y4376q25.fsf@rustcorp.com.au>
	<20160906112701.GA28919@nex> <87k2eo7b3g.fsf@rustcorp.com.au>
	<CAO3Pvs_WugO6CRMxHPZJ7QtaiTTb=1EFpBrbzKk_BbP8+=-nKA@mail.gmail.com>
	<8760piglkv.fsf@rustcorp.com.au>
	<CAO3Pvs8B0A5qu7GYVu8=uTYnd+miyuROM+RHz5Vt5Hd70-ce9w@mail.gmail.com>
	<20161003213457.GA9571@nex>
	<CALxbBHX9cg2fycBuw_btPz0WDCzfS7ViwkXVNs7LKdd9szepFw@mail.gmail.com>
	<CAO3Pvs8hzNicDryzS0K2Cg5ACx+f0p2mdPXckLzmrhQQ0xk55w@mail.gmail.com>
Message-ID: <20161021083059.GA14476@nex>

On Thu, Oct 20, 2016 at 10:26:07PM +0000, Olaoluwa Osuntokun wrote:
> When we agreed to include the payment hash in the MAC check within the
> header, I assumed that the packet format wouldn't be modified to include the
> payment hash (either in the header or e2e payload).
> 
> Instead, I envisioned that the payment hash would be a parameter to the
> packet processing/creation function. When creating or processing the packet,
> the payment hash would be concatenated to the material being authenticated
> similar to the "associated data" in AEAD cipher modes. With this scheme,
> there's no additional data added to the packets, but the payment hash is
> authenticated as part of packet processing at each hop.
> 
> So if an adversary attempts a replay, then they're forced to use the same
> payment hash, otherwise the packet won't propagate. Assuming all nodes
> remember all payment hashes, then replay attempts always fail and come at a
> direct monetary cost to the attacker.

Damn, I knew I was forgetting something, thank Laolu for the reminder,
I'll add that to the spec and the implementations.

Cheers,
Christian