lightning-dev
[BOLT Draft] Onion Routing Spec
Posted on: August 8, 2016 12:27 UTC
In an email thread, Olaoluwa Osuntokun and other participants discuss various options for including payloads in the header HMAC.
They prefer the first option which involves including payloads in the header HMAC computation because of its "fail fast" behavior and minimal overhead. The group also discusses anonymous rendezvous meetings and suggests using a version 0 packet to process the first two types of mix-header formats while a version 1 packet denotes a rendezvous packet. To prevent replay attacks, they propose including a timestamp rounded up to the closest hour in packets, with a sliding window of accepted timestamps of +/- 1 hour. The group weighs the trade-off between window size and storage overhead.The conversation concludes with a discussion on using the announced key as a root key for HD key derivation. They also discuss a proposed method for non-interactive key rotation in onion routing without compromising forward secrecy. This proposal involves using an HD Onion Key approach, authenticated via a signature of a schnorr multi-sign of the channel multi-sig key and the node's identity key. An intermediate onion derivation point is introduced to prevent compromise of the master root HD priv key. Each node pre-generates 365 keys to produce the final child onion key, then destroys the OD key to prevent an attacker from deriving the final child onion key.However, the group also discusses difficulties in enabling intermediate nodes to reply to a packet. One suggestion is to continue blinding the ephemeral key on the return path and sending a factor along with the header that tells each hop the current ephemeral key will be blinded by this factor. Unfortunately, this method was found to leak too much information about shared secrets or blinding factors.