[Feature] Noise XKpsk3 integration (2025 version)

[simonwicky]

Description

Noise PR #4360 is dead, long live Noise PR #5692.

No stacked PRs this time, commits description are quite explicit (and it's less of a mess than last time)

---

This change is 

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nym-explorer-v2	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 5, 2025 9:15am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
docs-nextra	⬜️ Ignored (Inspect)	Visit Preview		Jun 5, 2025 9:15am
nym-next-explorer	⬜️ Ignored (Inspect)	Visit Preview		Jun 5, 2025 9:15am

[timkuijsten]

Is there any rationale of the choice for XKpsk3? I.e. how to do DoS mitigation? Also I'm curious how this relates to the announcement of planning to use McEliece.

[aniampio]

@timkuijsten Thanks for the question! We decided to use XKpsk3 because it provides the best forward secrecy, authentication, replay protection, and identity-hiding guarantees for client-server settings where the client cannot be identified based on its source IP address. Also, as PQ-security is on our roadmap, we opted for the variant with PSK, as the pre-shared key can be later used to inject Post-Quantum safety into the protocol. We also decided to use the XKpsk3 between nodes, as we are considering supporting private gateways in the future, so the identity of the initiator may not be obvious from the source IP address (entry-mixnode). Then, for the rest of the connections (mix node to mix node, and mix node to exit) we also use the same pattern to keep the usage across the network uniform.

In terms of DoS protection, deploying Noise at the transport layer helps shield the Sphinx layer, as each message must first be validated by Noise before any Sphinx processing occurs. However, Noise itself can still be vulnerable to DoS attacks. WireGuard mitigates this risk using a cookie-based mechanism. We could adopt a similar approach, or explore alternative strategies — all of which are currently under consideration.

[timkuijsten]

In terms of DoS protection, deploying Noise at the transport layer helps shield the Sphinx layer, as each message must first be validated by Noise before any Sphinx processing occurs. However, Noise itself can still be vulnerable to DoS attacks. WireGuard mitigates this risk using a cookie-based mechanism. We could adopt a similar approach, or explore alternative strategies — all of which are currently under consideration.

I guess XK + cookie and making sure there is no responder-side state for unauthenticated connections (like rosenpass did) would put you in a good position. Are there already any public discussions, designs or transcripts?

[simonwicky]

@timkuijsten There are no public discussions or designs yet no.
Using cookies is a good lead, although it's just used to confirm the IP address so it can then be limited with other means.

[timkuijsten]

Using cookies is a good lead, although it's just used to confirm the IP address so it can then be limited with other means.

But nym uses TCP right? Isn't TCP's three-way-handshake enough for IP ownership confirmation? (unlike WireGuard which needs the cookie because it uses UDP).

[simonwicky]

@timkuijsten For the moment it does indeed. That's a fair point, I'll need to think about it.