From laolu32 at gmail.com Fri Sep 9 23:52:41 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Fri, 09 Sep 2016 23:52:41 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <87k2eo7b3g.fsf@rustcorp.com.au> References: <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> <871t1lefuo.fsf@rustcorp.com.au> <20160819183647.GB15105@lightning.network> <87pop1df71.fsf@rustcorp.com.au> <CAO3Pvs8B=ymN3o37QnMg5DexmNPJkVp6Md24qeetkL06h6dQMw@mail.gmail.com> <20160902120822.GA4575@nex> <87y4376q25.fsf@rustcorp.com.au> <20160906112701.GA28919@nex> <87k2eo7b3g.fsf@rustcorp.com.au> Message-ID: <CAO3Pvs_WugO6CRMxHPZJ7QtaiTTb=1EFpBrbzKk_BbP8+=-nKA@mail.gmail.com> Rusty Russell <rusty at rustcorp.com.au> wrote: > Each node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum + txnum). Using blocknum+txnum to identify a channel doesn't account for the possibility of a single transaction which opens multiple channels concurrently. A possible use-case for such a transaction are coin-joined channel openings which obfuscate the relationships being creating with a channel opening. You'd need to tack on an extra byte (maybe two) to also encode the output index of the channel within the transaction. Additionally, identifying channels based solely from blockheight+offsets conjures up some re-org safety concerns. It's also a bit less "verifiable" than referring via the full outpoint. > The proofs are larger: to prove which IDs owns a channel, each one needs a > merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can skip > some though), the two pubkeys (66 bytes), and a signature of the ID using > those pubkeys (128 bytes, schnorr would be 64?). Are those two pub keys the multi-sig pub keys, or the identity pub keys? In either case, only requiring two pub keys to attest-to/authenticate the state of a channel is insufficient. With only two signatures, then nodes can advertise the same channel several times creating a non-canonical graphs resulting in differing network views. If we'd like to eliminate such a possibility, then we also need to cryptographically bind the two identities to the proof. Using a schnorr multi-signature generated by the four pubkeys would remedy this. Validators can use pubkey recovery to extract the "group pubkey" from the single signature, ensure it's the result of point addition of the four public keys, check the channel isn't closed, then verify the signature over the advertisement as normal. Christian Decker <decker.christian at gmail.com> wrote: > I forgot that we have two potential key-rotations: > - Rotating the key used in transactions that hit the Bitcoin network If you mean the key included within the 2-of-2 multi-sig, I assume all implementations will be using a fresh key with each channel either way, so we don't need any explicit rotations here? I've only been thinking of rotations for the onion pubkeys used for the DH shared secret derivation for the onion packets. Identity keys could also possibly either be rotated/revoked, or delegated with some sort of "certificate". > Another case we could consider is having passive rotations: when an > endpoint announces a channel's existence it also sends its rotation > interval along. IMO a passive rotation scheme is superior due to the bandwidth savings of pushing the onion key rotations to the edges themselves. As you said an active rotation might be used in the emergency case of a forced key rotation due to key compromise. Rusty Russell <rusty at rustcorp.com.au> wrote: > Hmm, do we lose forward secrecy if we use a BIP32 chain? But we may be > able to use another derivation method where we derive key N from key > N-1. I'm looking at Laolu... Well, sorta. If the master pubkey is published, and nodes use public derivation on the edges to do passive key rotations, then if one of the non-hardened child private keys is leaked, an adversary can derive the master private key thereby gaining the ability to decrypt any saved/intercepted onion packets to the compromised node. Earlier in this email chain I suggested a scheme to regain forward secrecy in the case of such a private key leak by requiring nodes to do some upfront pre-computation involving an intermediate derivation point. This would still allow passive rotation by the edges. However, in practice those pre-generated would likely be stored in the same location? So that kinda puts us back at the original exploit scenario. If we were to involve some pairing crypto (IBE style), we would use say block hashes to allow nodes to passively derive keys the "source" node is able to generate the corresponding private key to... IMO we need to more clearly state our security model/assumptions here to reason about the attack scenarios we'll try to guard against. -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160909/486374b1/attachment.html>