Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-15 📝 Original message: ZmnSCPxj <ZmnSCPxj at ...
📅 Original date posted:2018-11-15
📝 Original message:
ZmnSCPxj <ZmnSCPxj at 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
📝 Original message:
ZmnSCPxj <ZmnSCPxj at 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