[Lightning-dev] [BOLT Draft] Onion Routing Spec

Olaoluwa Osuntokun laolu32 at gmail.com
Mon Oct 3 17:21:35 UTC 2016


> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20161003/6a86cc38/attachment.html>


More information about the Lightning-dev mailing list