From laolu32 at gmail.com Mon Oct 3 17:21:35 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Mon, 03 Oct 2016 17:21:35 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <8760piglkv.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> <20160902120822.GA4575@nex> <87y4376q25.fsf@rustcorp.com.au> <20160906112701.GA28919@nex> <87k2eo7b3g.fsf@rustcorp.com.au> <8760piglkv.fsf@rustcorp.com.au> Message-ID: > I think this only works if the on-chain keys are Schnorr, right? We'd use the same curve equation and domain parameters as Bitcoin uses currently, but would swap out EC-DSA for EC-Schnorr. So as a result, pub/priv keys stay the same, meaning the on-chain keys can be used for signing/verifying the multi-sign for channel authentication proofs. > Indeed. Let me try to enumerate the different secrets we need to > protect, and you tell me what I missed? Excellent, this looks like an accurate breakdown to me. The only thing I'd add is that compromise of the identity public key allows an attacker to open/accept authenticated+confidential p2p connections on the network. In isolation this seems pretty harmless as they're capabilities with one this key is rather limited. >From a compartmentalization standpoint, unless there are significant gains from coupling keys from distinct categories, all keying material should be as independent as possible. At the very least (as you detailed), the commit keys should be rolled anew for each channel. This opens up the doors to architectures such as per-channel process signers w/ mlock'd secrets, dedicated hardware, etc. > Separating onion privkey allows rotation; only a win if we get forward > secrecy (not a win for this node, as much as for the network as a > whole). Agreed, if we're not initially doing passive (or active) key rotation for the onion keys, then coupling the identity and onion keys simplifies the code at that level and nixes a few network layer control messages. > The comms symmetric key should be rotated with forward secrecy as > well, for similar reasons. Indeed, we can throw in a simple ratcheting scheme into the initial p2p spec. -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: