From rusty at rustcorp.com.au  Sun Dec 20 19:31:38 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 21 Dec 2015 06:01:38 +1030
Subject: [Lightning-dev] An Alternative Onion-Routing Proposal
In-Reply-To: <CAO3Pvs8X=xuFNJw7W+XUZmYxYxdC0EGmOAyiUjt7s4X8ydWBzg@mail.gmail.com>
References: <CAO3Pvs9kM1W2pM-qE59HeE2wXG-xg1QBRek1RueVqe=3LOAbiQ@mail.gmail.com>
	<87wpsgh28z.fsf@rustcorp.com.au>
	<CAO3Pvs8aNBHEEBGLghgKCeCpgXoWHiotL_uN2Rzj3D+ib75nRA@mail.gmail.com>
	<87d1u7xoxl.fsf@rustcorp.com.au>
	<CAM_a8JwS1BEdbN8sOYu4iq8E9__VD6WHQ4-X1SGX7nZaKE26hQ@mail.gmail.com>
	<CAO3Pvs8X=xuFNJw7W+XUZmYxYxdC0EGmOAyiUjt7s4X8ydWBzg@mail.gmail.com>
Message-ID: <87wps8nch1.fsf@rustcorp.com.au>

Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Sure. If we end up going with cha cha, I'd like us to adopt the practice of
> encrypting the packet lengths with a separate key (and a new instance of
> chacha20)  similar to openssh's chacha20-poly3015 specification[2]. With
> this construction, packet-length+packet-payload remain confidential.

Nice!  While timing and packet boundary measurement will probably be
quite effective at determining sizes anyway, let's not make it easy.

Note that we have to handle some limited re-transmission, due to nodes
going down.  The protocol assumes nodes store things persistently, but
of course there can be packet loss / connection issues.

Since our protocol is basically command/response, a node should respond
to retransmission by retransmitting the response.  (There are a few
corner cases where we need to re-xmit more than one, but you get the
idea).

Cheers,
Rusty.