Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-02 📝 Original message: Olaoluwa Osuntokun ...

📅 Original date posted:2016-08-02
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> A special HMAC value of 20 0x00 bytes indicates that the currently
>> processing hop is the intended recipient and that the packet should not be
>> forwarded. At this point the end-to-end payload is fully decrypted and the
>> route has terminated.
>
> It seems that with the current construction, then the "next hop" address
> will
> also be zero bytes if a packet processor is the last hop in the route.
> Alternatively, if the sender is aware that the receiver is actually a
> "virtual
> channel", then an additional address could be used instead of the
> zero-address
> to facilitate de-multiplexing at the last hop to the destination virtual
> channel.

Hmm, I think we should combine the "header" and "per-hop payload" into a
single 40 byte field. They're not meaningfully distinct for lightning,
AFAICT.

And I think we should add/steal at least one byte for "realm". 0 =
terminal. 1 = bitcoin lightning. 2 = TBA. etc.

Obviously we should specify the layout when type = 0 (ignore) and 1
(hash160(nexthop-pubkey) + 8-byte-amount-to-fwd + 12-ignored).

That allows us to extend the protocol incompatibly (add a new realm) or
compatibly (add semantics to those ignored sections).

> First, lets talk replay protection. The current draft specifies that:
>
>> The node MUST keep a log of previously used shared secrets. Should the
> shared
>> secret already be in the log it MUST abort processing the packet and
> report a
>> route failure, since this is likely a replay attack, otherwise the shared
>> secret is added to the log
>
> This is definitely necessary, however as dictated this would require nodes
> to
> allocate a potentially *unbounded* amount of storage to the shared secret
> "seen" log. I think we can allow nodes to periodically truncate this log by
> adding an additional session time stamp to the mix-header, either placed
> directly after the version byte, or within the per-hop payload.

Let's tease this out a bit more; thinking about replays from the PoV of
one layer higher. We can't simply deny multiple HTLCs with the same r
hash, since that allows an attacker to probe the network to see where an
HTLC went (note that in the longer run, it's in a node's short-term
economic interest to allow this, which is why rhash is troubling).

If we switch from hash/preimage to the privkeys with point addition
scheme (which has other benefits) this is no longer an issue and we can
simply refuse to accept two HTLCs with the same pubkey.

Though the idea of using a "comms" key signed by our "peer" key which we
rotate every N minutes/hours is appealing for forward secrecy and
minimal peer-key exposure reasons, as Laolu says.

Cheers,
Rusty.