Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Upgrade rendezvous KeyExchange to a v1-style transcript-bound key derivation

Open
  • Is something wrong?
#709 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
backend-api-design, networking, security

Research direction

Start with rendezvous.proto, then read handle_listener_inner and the KeyExchange arm in handle_tcp. Compare the existing client-side version selection in rustdesk's common.rs and the Kx v1 tests from #16326. Done means version negotiation, v0 compatibility, v1 split-key exchange, and downgrade-tampering coverage work for rendezvous connections.

Written by the indexing model from the issue text.

Description

Context

#706 fixed a real bug where hbbs never sent a KeyExchange message at all in TCP (secure_tcp) mode, leaving clients waiting forever (#394). That fix uses the original ("v0") scheme: one shared symmetric key for both directions, derived via Encrypt::decode/box_::seal.

During review, rustdesk/rustdesk#16326 ("Kx v1") was flagged as a possibly-related upgrade already available in hbb_common. Traced it down (see this comment on #706 for the full analysis):

  • #16326 added kx_version to PublicKey in message.proto — the direct peer-to-peer connection handshake (client-to-client, relayed via hbbr).
  • rendezvous.proto's own KeyExchange (the hbbs-to-client rendezvous handshake #706 fixes) is a different message, untouched by #16326, and has no version field.

So the v1 upgrade doesn't apply to rendezvous connections automatically — but the underlying crypto primitives it introduced in hbb_common (tcp::Encrypt::new_split, tcp::KxTranscript, kx_version_for) are generic and already available. Adopting them for the rendezvous handshake too would give it the same improvement #16326 gave the peer-to-peer one: per-direction split keys derived from a transcript that binds both ephemeral public keys and the negotiated version, closing the downgrade-attack surface a single shared v0 key leaves open.

Proposed scope

  1. Add a kx_version field to KeyExchange in rendezvous.proto (mirroring PublicKey's new field), defaulting to absent/0 for backward compatibility with clients that don't send it.
  2. Server (handle_listener_inner) advertises kx_version_for(KX_VERSION_LATEST) alongside its existing signed ephemeral key.
  3. Client picks the highest mutually-supported version (existing client-side logic in rustdesk/rustdesk's common.rs already does this for the peer-to-peer case — same pattern, different message).
  4. Server (handle_tcp's KeyExchange arm) branches on the picked version: 0 keeps today's Encrypt::decode/Encrypt::new, 1 builds a KxTranscript (initiator/responder ephemeral pubkeys + advertised/picked versions) and calls Encrypt::new_split.
  5. Tests mirroring #16326's own: version compatibility, bidirectional exchange, downgrade-tampering (a MITM forcing version 0 when both sides support 1 should be detectable/rejected, matching the transcript-binding's whole point).

Why a separate PR

#706 is a narrow, already-tested fix for a real, currently-broken connection path (real user confirmed fixed). This is a genuine security hardening on top of a now-working baseline, not a blocker for it — better scoped, reviewed, and tested independently.

Dominant language
Rust
Stars
10.4k
Forks
2.6k
No merged PRs in 30d

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rustdesk/rustdesk-server

All issues in rustdesk/rustdesk-server

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.