RustDeskandClaude Opus 5.5 e424b57fca Kx v1 (#16326)
* key exchange version 1 on the rendezvous and peer handshakes

Bump hbb_common for key exchange version 1, one stream key per direction,
and negotiate it on both handshakes.

Rendezvous: `secure_tcp` reads the version the server advertises in
`KeyExchange.version`, answers with the highest both speak, splits the key
when that is at least 1, and arms the check of the server's echo on its first
encrypted message.

Peer: the controlled side advertises `KX_VERSION_LATEST` inside the signed
`IdPk`, the controller answers in `PublicKey.kx_version` and both split the
key when the pick is at least 1. A pick above what was offered is refused as
a bug or tampering. `decode_id_pk_dtls` returns the advertised version along
with the fingerprint.

An absent field on either side is version 0, so any old peer or server keeps
today's stream byte for byte.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* bump hbb_common: keep the advertisement check armed until an echo arrives

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab

* bump hbb_common: drop box_pk_of until something calls it

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab

* key exchange: say 0 on WebRTC, where no stream key applies

A WebRTC stream is encrypted by DTLS and `set_key_split` collapses to
`set_key` on it, which sets nothing but `peer_verified`. Both sides still
put 1 on the wire, the controlled peer in its signed identity and the
controller in its pick, and agreed on a version neither applied. That held
only because both fell into the same branch: the day one side splits keys
on WebRTC and the other does not, they would agree on 1, derive different
keys, and have no version mismatch to point at.

The controlled peer now advertises 0 on WebRTC and refuses a pick above
what it advertised rather than above the newest it speaks anywhere; the
controller picks 0 there. What is on the wire is what runs.

Also bumps hbb_common for the echo contract: the server tags every
message after the exchange, not the first alone, so dropping one frame at
a known position does not rid an attacker of the downgrade check.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab

* key exchange: verify the server's signed version before trusting it

bump hbb_common d9f519e: KeyExchange.signed_version

A server that signs its version sets bit 255 of the ephemeral key inside
the signed keys[0]. A client that sees that bit, or the field itself,
verifies sign("rdkx-ver" || key || version LE) under the server's signing
key before picking a version and refuses the exchange otherwise, so a
version lowered in the clear is caught at the handshake rather than one
frame pair later by the echo. A legacy server sends canonical keys and no
field and takes the unchanged path; the echo still checks its version.

Tests: version 1 keys match the server both ways; an advertisement
lowered in transit is refused at the first echo; legacy, signed-1 and
signed-3 servers each exchange application data; nine tamperings of the
signed version are refused before the client replies.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* key exchange: comments say what the fields and functions are

bump hbb_common e3452ac: the same on the shared side.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* key exchange: drop the advertisement echo

bump hbb_common 5194159: RendezvousMessage.kx_advertised and the check on
decrypted frames are gone. signed_version settles the version inside the
exchange, so the client arms nothing after it; the stub in the tests
stops tagging its frames and the test of a lowered advertisement goes,
the signed-version cases covering that refusal before any reply.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* key exchange: verify KxParams, the server's signed structure

bump hbb_common e74a188: KeyExchange.signed_params and KxParams.

The client parses the signed bytes as KxParams and compares its fields
to the key it verified and the version it was shown, rather than
matching a fixed byte string, so a field added to KxParams later parses
past an older client. The tamper cases now include a payload signed as
the old byte string.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* key exchange: require the KxParams signing prefix before parsing

bump hbb_common 26582e1: KX_PARAMS_DOMAIN.

Without it a signed IdPk, which the server signs with the same key,
parsed as a KxParams whose pk was the id and whose version was 0, so an
id registered with the bytes of a marked ephemeral key could stand in
for the params at version 0. Two tamper cases pin this: params signed
without the prefix, and a signed IdPk in their place.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* key exchange: one call sets the negotiated key

bump hbb_common cbc8772: Stream::set_negotiated_key.

The rendezvous client, the controller and the controlled side each
branched on the picked version to choose between split and single keys.
They now hand the transcript to Stream, which makes that choice once.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* Update hbb_common: refuse unknown key exchange versions, pin wire vectors

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* client: prove the peer handshake picks its version and encrypts under it

The rendezvous exchange had tests against a stub server; the peer
handshake had none, so a controller that fell back to version 0 would
still connect, still report secured, and pass every test. These run
Client::secure_connection against a stub controlled peer and check
the pick it sees and the application data both ways: new peers pick 1,
a peer without versions gets 0, and a pick lowered in transit leaves
the two sides unable to read each other.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* Update hbb_common: pin the subkeys for an advertisement above the pick

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* Update hbb_common to main, with #614 merged

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

* key exchange: name the picked version, say why the marker bit is safe

Review follow-ups with no change in behaviour: the rendezvous pick is
called picked, as in the peer handshake and KxTranscript; the marker
comment says X25519 ignores the bit and the bytes stay as signed; the
controlled side's refusal names the version it offered.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-23 17:30:22 +08:00
2026-06-18 22:37:15 +08:00
2026-09-22 15:18:10 +08:00
2026-09-01 08:57:33 +08:00
2026-09-22 16:12:11 +08:00
2026-09-23 17:30:22 +08:00
2026-09-23 17:30:22 +08:00
2026-09-22 15:18:10 +08:00
2026-09-06 00:21:28 +08:00
2026-05-26 11:45:15 +08:00
2026-04-09 15:12:57 +08:00
…
2026-08-25 19:53:56 +08:00

RustDesk - Your remote desktop
Build • Docker • Structure • Screenshots
[Українська] | [česky] | [中文] | [Magyar] | [Español] | [فارسی] | [Français] | [Deutsch] | [Polski] | [Indonesian] | [Suomi] | [മലയാളം] | [日本語] | [Nederlands] | [Italiano] | [Русский] | [Português (Brasil)] | [Esperanto] | [한국어] | [العربي] | [Tiếng Việt] | [Dansk] | [Ελληνικά] | [Türkçe] | [Norsk] | [Română]
We need your help to translate this README, RustDesk UI and RustDesk Doc to your native language

Caution

Misuse Disclaimer:
The developers of RustDesk do not condone or support any unethical or illegal use of this software. Misuse, such as unauthorized access, control or invasion of privacy, is strictly against our guidelines. The authors are not responsible for any misuse of the application.

Chat with us: Discord | Twitter | Reddit | YouTube

RustDesk Server Pro

Yet another remote desktop solution, written in Rust. Works out of the box with no configuration required. You have full control of your data, with no concerns about security. You can use our rendezvous/relay server, set up your own, or write your own rendezvous/relay server.

image

RustDesk welcomes contribution from everyone. See CONTRIBUTING.md for help getting started.

FAQ

BINARY DOWNLOAD

NIGHTLY BUILD

Get it on F-Droid Get it on Flathub

Dependencies

Desktop versions use Flutter or Sciter (deprecated) for GUI. This tutorial is for Sciter only, since it is easier and more friendly to start. Check out our CI for building the Flutter version.

Please download Sciter dynamic library yourself.

Windows | Linux | macOS

Raw Steps to build

  • Prepare your Rust development env and C++ build env

  • Install vcpkg, and set VCPKG_ROOT env variable correctly

    • Windows: vcpkg install libvpx:x64-windows-static libyuv:x64-windows-static opus:x64-windows-static aom:x64-windows-static
    • Linux/macOS: vcpkg install libvpx libyuv opus aom
  • run cargo run

Build

How to Build on Linux

Ubuntu 18 (Debian 10)

sudo apt install -y zip g++ gcc git curl wget nasm yasm libgtk-3-dev clang libxcb-randr0-dev libxdo-dev \
        libxfixes-dev libxcb-shape0-dev libxcb-xfixes0-dev libasound2-dev libpulse-dev cmake make \
        libclang-dev ninja-build libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev

openSUSE Tumbleweed

sudo zypper install gcc-c++ git curl wget nasm yasm gcc gtk3-devel clang libxcb-devel libXfixes-devel cmake alsa-lib-devel gstreamer-devel gstreamer-plugins-base-devel xdotool-devel

Fedora 28 (CentOS 8)

sudo yum -y install gcc-c++ git curl wget nasm yasm gcc gtk3-devel clang libxcb-devel libxdo-devel libXfixes-devel pulseaudio-libs-devel cmake alsa-lib-devel gstreamer1-devel gstreamer1-plugins-base-devel

Arch (Manjaro)

sudo pacman -Syu --needed unzip git cmake gcc curl wget yasm nasm zip make pkg-config clang gtk3 xdotool libxcb libxfixes alsa-lib pipewire

Install vcpkg

git clone https://github.com/microsoft/vcpkg
cd vcpkg
git checkout 2023.04.15
cd ..
vcpkg/bootstrap-vcpkg.sh
export VCPKG_ROOT=$HOME/vcpkg
vcpkg/vcpkg install libvpx libyuv opus aom

Fix libvpx (For Fedora)

cd vcpkg/buildtrees/libvpx/src
cd *
./configure
sed -i 's/CFLAGS+=-I/CFLAGS+=-fPIC -I/g' Makefile
sed -i 's/CXXFLAGS+=-I/CXXFLAGS+=-fPIC -I/g' Makefile
make
cp libvpx.a $HOME/vcpkg/installed/x64-linux/lib/
cd

Build

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
git clone --recurse-submodules https://github.com/rustdesk/rustdesk
cd rustdesk
mkdir -p target/debug
wget https://raw.githubusercontent.com/c-smile/sciter-sdk/master/bin.lnx/x64/libsciter-gtk.so
mv libsciter-gtk.so target/debug
VCPKG_ROOT=$HOME/vcpkg cargo run

How to build with Docker

Begin by cloning the repository and building the Docker container:

git clone https://github.com/rustdesk/rustdesk
cd rustdesk
git submodule update --init --recursive
docker build -t "rustdesk-builder" .

Then, each time you need to build the application, run the following command:

docker run --rm -it -v $PWD:/home/user/rustdesk -v rustdesk-git-cache:/home/user/.cargo/git -v rustdesk-registry-cache:/home/user/.cargo/registry -e PUID="$(id -u)" -e PGID="$(id -g)" rustdesk-builder

Note that the first build may take longer before dependencies are cached, subsequent builds will be faster. Additionally, if you need to specify different arguments to the build command, you may do so at the end of the command in the <OPTIONAL-ARGS> position. For instance, if you wanted to build an optimized release version, you would run the command above followed by --release. The resulting executable will be available in the target folder on your system, and can be run with:

target/debug/rustdesk

Or, if you're running a release executable:

target/release/rustdesk

Please ensure that you run these commands from the root of the RustDesk repository, or the application may not find the required resources. Also note that other cargo subcommands such as install or run are not currently supported via this method as they would install or run the program inside the container instead of the host.

File Structure

Screenshots

Connection Manager

Connected to a Windows PC

File Transfer

TCP Tunneling

Languages
Rust 70.2%
Dart 21.6%
Python 1.8%
C++ 1.6%
C 1.5%
Other 3.1%