Edit: i appreciate the explanations; thank you.
It consumes, on the client, 800%-1200% CPU AND 8%-10% GPU decode on my NVIDIA card. I opened a bug and they transformed it into a discussion, without any response.
That's what made me uninstall RustDesk.
If you're experiencing a bug that pegs you're CPU, fair enough. But RustDesk is video-stream based (in many formats), while TightVNC is image(-region) based. This is actually similar to why you watch movies in, say, H.264 rather than Motion JPEG¹.
¹=similar, not same.
If you already use VNC this is not something for you
Not that RealVNC is VNC. However, enshittification has clearly taken another scalp.
How does RustDesk compare with that?
GNOME Remote Login runs an RDP server, and RDP indeed isn’t fast enough, although is TLS-encrypted.
There's VNC and VNC-likes (rdp, steam link, rustdesk, etc) which all do similar: stream a screen, allow remote keyboard/mouse, maybe redirect sound, maybe use video encoders.
There's also things like deskflow, which allow you to use one keyboard/mouse and control with multiple machines.
Does it framebuffer grab the current session and inject input events?
It entirely sidesteps the problem of X vs Wayland, although this does mean the unattended physical seat can be physically taken over while you are remote.
So far it's only feature I found missing compared to proprietary solutions.
I will note that the XKCD password scheme being proposed there is, in fact, completely insecure. A modern consumer GPU can crack "four random English words" in a day. You can argue that it's the user's choice to be allowed to use insecure passwords, but arguing that that scheme is actually secure is just wrong.
Let's run the math:
EFF's long wordlist[0] (the one used by Bitwarden's passphrase generator) has 7776 words, which is about 13 bits of entropy per word (log2(7776) = 12.92). A 4-word passphrase then has 51.7 bits of entropy, meaning there are 2^51.7 possible options for the passphrase, which is 3.66E15 possible options.
For reference, a password with all completely random characters and symbols, for each character you have 70 possibilities, or about 6 bits of entropy. An 8-character completely random password (no words or the usual patterns) then has about 49 bits of entropy, which is less than a 4 word passphrase.
About the time it takes to crack it, assuming you can test an average of 1 password per μs (you probably can't, as passwords are usually stored using key derivation functions[1][2] with work factors tweaked for current hardware) it would take ~116 years to crack it. I usually see 5-passphrase recommended nowadays, which would multiply the required effort by 7776.
Sure, a 16-character random password has a lot more entropy, but it's also a lot harder to interact with (reading, comparing, typing) if you end up needing to, and it's still easier to crack than an 8-word passphrase.
[0] https://www.eff.org/dice [1] https://en.wikipedia.org/wiki/Key_derivation_function [2] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
You are not (usually) in control of what services use to encrypt your password, and most software in the world uses a basic hash like MD5 or SHA-256 rather than a key derivation function, meaning you are wildly, wildly underestimating the number of guesses per second here. To suggest that passwords are "usually" stored like that is just wildly incorrect. Only well-educated, high-quality engineers who care about security, a vanishingly tiny portion of the industry, even think about things like this. I still run into government services that e-mail me my password in plaintext.
---
Sorry, but edit attaching a reply to another comment here because HN rate-limits me:
> This is just completely false.
My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second), or about 3 days against SHA-256 (6.5 billion guesses per second). A desktop 4090 would likely crack SHA-256 in under a day (on average).
I make claims with confidence because I am speaking about facts. Why are you making claims with confidence when you have no idea what you're talking about? The quality of discourse on this site is so, so low.
> A modern consumer GPU can crack "four random English words" in a day
What you're saying now:
> My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second)
So your response to the plain mathematical fact that, no, your consumer GPU cannot crack "four random English words" in a day, is that your consumer GPU can crack four words chosen from a list of a few thousand, in a day. Followed by personal attacks. Okay.
Trying to pick a strong password assuming the service you’re signing up for doesn’t care about security is pointless. You’ll be pwned regardless of what you do.
For passwords? Where do you get that information?
Even if only 10% of the services you use use MD5/SHA-256 (although I certainly would expect it to be >50% if we could do a large-scale study), why accept your password being easily compromised 10% of the time?
Let me do just that!
This is a networked service. You send your password (or a hashed form) to it, and it validates it. You don't have the local hash to bruteforce it offline.
Even if we only consider the top 10k english words, it's 10000^4. It's going to take years to bruteforce this over a network because you'll go through so many rate-limits, cooldown periods, and outright bans that it's questionable whether it's even possible.
Hopefully neither. But given everybody involved in VNC seems to be the same batch of clueless morons who built all those PHP web forums twenty years ago with MD5 as the password hash, who knows what they cobbled together. Maybe an expert can chime in about what actually happens here?
Yes, for a sensible scheme this can't work.
I would recommend never using this software.
[1]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2... [2]: https://github.com/rustdesk/rustdesk/discussions/8392 [3]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2... [4]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2...
This is just completely false.
I proposed replacing the ridiculous checklist with zxcvbn.
I agree xkcd's scheme is a bad example and distracts from the real point, which is that a checklist is fundamentally bad, not that some specific password format should be allowed.
Sure, if you can rely on users using a specific format. The joy of the xkcd technique is you don't need to tell other people what yours is.
But, people just aren't going to remember strings of gibberish. Expecting users to do this is just silly.
If you were willing to use a bespoke, more secure variation of it, you could include a capital letter and a number rather than filing an issue on a repo insisting that you be allowed to use exactly the insecure variation.
For instance, I have multiple separator characters, multiple beginning and end characters, and numbers places at specific places, and arbitrary casing. That may be overkill but it's still essentially the xkcd format.
XKCD's youtube videos get millions of views each. It is a very popular comic, and that particular password advice has spread beyond it.
> What you describe as "bespoke" is likely the normal way someone might use it.
And yet the issue in question is about someone who refuses to adapt it.
Tayloring your format to the requirements of each site is a step towards defeating the utility of the system; now the user needs to remember some arbitrary hard-to-remember details for each password.
Although having a standard format for your passphrases across sites removes some of the advantages over just using the exact xkdc format (when one of your passwords is compromised and attackers can guess your custom format elsewhere now)...
Does this person exist?
I have used RustDesk for years, also run my own lookup/relay server so I do not need to rely on the public lookup server
While everything else gets enshitified RustDesk just keeps getting better
And the fact it's self-hosted is priceless.
Now, VNC might actually also work very well over WireGuard or SDN based on WireGuard. Since VNC was designed for LAN, in a time where LAN was the common use case.
For me, low latency is from the past. I always got either wired, Wi-Fi, LTE, or Starlink.
VNC does not, for example, and you need to set up port forwarding through ssh. X2Go does....but I don't trust it terribly. So, RustDesk..what do you need to wrap it in? ssh?
I really want a better solution that VNC/X2Go..especially since I use hardware accelerated apps that need to use VGL to operate correctly (but underwhich operation is quite buggy).
basically an embedded tailscale.
Please just make it work seamlessly with my existing SSH credentials. Like SFTP.
Nothing prevents RustDesk from implementing TLS TOFU (see e.g. Gemini Protocol), which offers the same security guarantees as SSH TOFU.
But yeah, you could also make use of your ed25519 ssh public key as client certificate and accept based on fingerprint like ssh
"We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default.
For security and privacy, we strongly advise using it in combination with a VPN—the VPN tunnel already provides end-to-end encryption, so additional encryption within RustDesk is unnecessary in that setup.
That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! "
hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
Factually incorrect. If you self host a relay/coordination server - encryption works as documented.
[1] https://github.com/rustdesk/rustdesk/issues/3714#issuecommen...
1 - https://github.com/rustdesk/rustdesk/issues/3714#issuecommen...
>RustDesk is a single open-source application (AGPL) with its own architecture. Clients connect outward to an ID/rendezvous server, which brokers a peer-to-peer or relayed session. Per the RustDesk documentation, traffic is end-to-end encrypted (built on NaCl)