ZmnSCPxj <zmnsc...@protonmail.com> writes: > The construction we came up with allows multiple rendezvous nodes, > unlike the HORNET construction that is inherently only a single > rendezvous node. Perhaps the extra flexibility comes with some > security degradation?
I don't think this is the case. If I remember correctly (Conner please correct me if I'm wrong here), then the Hornet rendez-vous construction relied on a Sphinx packet from the RV to R, wrapped in a Sphinx packet from S to RV. This was possible because of the variable sized payload. It would be possible to do that a number of times, with the downside that the packet would be bigger and bigger since we are wrapping full Sphinx packets. Our construction with the ephemeral key switch at the rendez-vous point is identical to that construction, except that we have the ephemeral key at the RV hidden inside the routing information (per-hop payload) and the remainder of the route in what would otherwise be padding. The constructions are IMHO no different except for the location we store the forward information that the RV will have to unpack (per-hop payload instead of nested sphinx packets). The only difficulty that I pointed out comes from the fact that the HMAC verification can't work if we can't generate a specify shared secret at the RV, which to me sounds like an intrinsic property of the way we use one-way functions to derive those. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev