📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:52:27
in reply to nevent1q…20rq
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:52:27Event JSON
{
"id": "ea8ca517b03773cc1d3cc3e8debcb32f52ddd9f160f1e0b090c2263fdade8bd0",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315147,
"kind": 1,
"tags": [
[
"e",
"f4b5ffab7a9c96d8928a76b4653d399422785cf29dac19cdb8e24eff6d895c9a",
"",
"root"
],
[
"e",
"7e189185e4f9831ecb8ee48b68dd67b20f5dab016cb49d0e34d059add1d91799",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-15\n📝 Original message:\nZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e writes:\n\u003e The construction we came up with allows multiple rendezvous nodes,\n\u003e unlike the HORNET construction that is inherently only a single\n\u003e rendezvous node. Perhaps the extra flexibility comes with some\n\u003e security degradation?\n\nI don't think this is the case. If I remember correctly (Conner please\ncorrect me if I'm wrong here), then the Hornet rendez-vous construction\nrelied on a Sphinx packet from the RV to R, wrapped in a Sphinx packet\nfrom S to RV. This was possible because of the variable sized payload.\nIt would be possible to do that a number of times, with the downside\nthat the packet would be bigger and bigger since we are wrapping full\nSphinx packets.\n\nOur construction with the ephemeral key switch at the rendez-vous point\nis identical to that construction, except that we have the ephemeral key\nat the RV hidden inside the routing information (per-hop payload) and\nthe remainder of the route in what would otherwise be padding. The\nconstructions are IMHO no different except for the location we store the\nforward information that the RV will have to unpack (per-hop payload\ninstead of nested sphinx packets).\n\nThe only difficulty that I pointed out comes from the fact that the HMAC\nverification can't work if we can't generate a specify shared secret at\nthe RV, which to me sounds like an intrinsic property of the way we use\none-way functions to derive those.\n\nCheers,\nChristian",
"sig": "390ba4d2e8ba8aaf75bdb78de6e74ee67e31b79c0c3dfa1b613d45f9b761794b909eb0aa24d00ff7e026fb13d656a7db06dfca85ed4b28da805d67b706670273"
}