Working principle

[lucasjinreal]

How does it work? Any docs? Caused users concerning about the security itself without looking the code. Does it requires a good spec centeric server? what's the minimal requirements of it ?

[rustdesk]

https://rustdesk.com/docs/en/
https://github.com/rustdesk/doc.rustdesk.com

[rustdesk]

Doc is still incomplete.

[zuoxinyu]

Seems an architecture introduction is needed.

[rustdesk]

architecture introduction

I am really not good at this, our design is very straightward, I do not like design patterns etc. Everything is in my mind, but I do not know how to draw or write on the paper.

@fufesou you seems good at drawing diagram and flow chart, could you help?

[chiehw]

I draw a draft.

[rustdesk]

draft

Good job! :)

[chiehw]

Caused users concerning about the security itself without looking the code.

Security check locally, make sure your password is complex enough.

what's the minimal requirements of it ?

Depends on video transmission quality. These servers do not need high performance, you only need to consider the bandwidth of the relay server.

[rustdesk]

ID / Pasword (encrypted) does not go to server 1. It goes to relay server or directly to remote PC (if NAT succeeds).

[chiehw]

ID / Pasword does not go to server 1.

Ok, I fix it soon.

[chiehw]

I steal it from https://cloud.tencent.com/developer/article/1897847

And I draw a simple depoyment diagram to supply some additional information.

[chiehw]

ID / Pasword (encrypted) does not go to server 1

Yeah, the password is generated locally, this draft is wrong.

[rustdesk]

I will put your diagram into a wiki.

[rustdesk]

https://github.com/rustdesk/rustdesk/wiki/How-does-RustDesk-work%3F

[chiehw]

I will put your diagram into a wiki.

I steal the first diagram from https://cloud.tencent.com/developer/article/1897847

[rustdesk]

@asur4s The first diagram is a little out of date, B's pk in step 9 is also encrypted in new version.

[rustdesk]

https://github.com/rustdesk/rustdesk/blob/master/src/client.rs#L354

[chiehw]

Ok, I'll read this part of the code carefully to fix the first diagram.

[chiehw]

Ok, I'll read this part of the code carefully to fix the first diagram.

The time is late.

I've simplified a lot of information for a better understanding of how rustdesk works, You can also modify it online at this link

[rustdesk]

understanding

Good Job!

[chiehw]

Is this part correct?

[rustdesk]

correct

Looks ok

[rustdesk]

Here, you'd better change remote pk to encrypted remote pk

[chiehw]

Ok

[WaleedMortaja]

@rustdesk @asur4s
If you allow me, I would suggest updating the image in the wiki to the latest image. I would even better suggest removing the wiki, and merging its content to the docs, making the docs the unified central information reference.

For the latest image provided here, I have some questions

1. So, the clients generate public/private key pair independent of the the key of hbbs? May be that phase could be added before the first phase in the diagram?
2. Is the data in the "register" phase encrypted? Maybe using the public key entered in "ID/Relay Server" config?
3. If one, or both if the clients did not set the hbbs key, why is the connection marked as "not encrypted"? Is not the connection between the client already encrypted using the symmetric key in the last phase?
4. How does a rely server affect the encryption?
5. Can you add a key-map of the abbreviations and ambiguous keys, like ID and UUID. What is the difference? Does Address refer to IP Address?
6. In Steps 11 & 12, How could "Client A" decrypt the data that is encrypted by "B's SK". Is "B's SK" sent in step 10?

One last (Mostly off-topic) question: What does hbbs and hbbr stand for?! I know they are the rendezvous and relay serves, but I can not see how hbbs stands for rendezvous server for example?

Sorry for writing too long and thank you very much for the amazing software!

[akiross]

Github supports mermaidjs, so it's possible to draw some simple diagrams using code.

I'm sharing the code of a sequence diagram so you can place that in the wiki or doc and change it with ease.

I'm not sure about how hbbr are used, so I guessed a bit in the last part.

```mermaid
sequenceDiagram

  participant client A
  participant hbbs
  participant hbbr
  participant client B

  Note over client A, client B: Registration of client A
  
  client A ->> hbbs: 1. Register with hbbs
  hbbs ->> hbbs: 2. Save peer info
  Note right of hbbs: ID, Address, UUID, PK
  hbbs -->> client A: 3. Register response 

  Note over client A, client B: Registration of client B

  client B ->> hbbs: 4. Register with hbbs
  hbbs ->> hbbs: 5. Save peer info
  hbbs -->> client B: 6. Register response

  client B ->> hbbs: 7. Request to establish connection<br/>with RemoteID by punching hole
  hbbs ->> client A: 8. Request remote addr
  client A -->> hbbs: 9. Return remote
  Note left of client A: Remote addr, Relay server addr
  hbbs ->> client B: 10. Return remote info
  Note right of client B: Remote addr, encrypted PK

  Note over client A, client B: Establish a secure connection key exchange

  client A ->> client B: 11. B's TPK encrypted with B's SK
  client B ->> client B: 12. Decrypt B's TPK, generate, new keypair

  client B ->> client A: 13. Sealed symmetric A's TPK
  client A ->> client A: 14. Decrypt, get symmetric TPK/TSK

  Note over client A, client B: Encrypted communication by using symmetric key

  client B ->> hbbr: 15. Control data
  hbbr ->> client A: 15. Control data
  Note left of client A: Keyboard, Mouse
  client A ->> hbbr: 16. Audio frame, video frame, clipboard
  hbbr ->> client B: 16. Audio frame, video frame, clipboard

```

sequenceDiagram

  participant client A
  participant hbbs
  participant hbbr
  participant client B

  Note over client A, client B: Registration of client A
  
  client A ->> hbbs: 1. Register with hbbs
  hbbs ->> hbbs: 2. Save peer info
  Note right of hbbs: ID, Address, UUID, PK
  hbbs -->> client A: 3. Register response 

  Note over client A, client B: Registration of client B

  client B ->> hbbs: 4. Register with hbbs
  hbbs ->> hbbs: 5. Save peer info
  hbbs -->> client B: 6. Register response

  client B ->> hbbs: 7. Request to establish connection<br/>with RemoteID by punching hole
  hbbs ->> client A: 8. Request remote addr
  client A -->> hbbs: 9. Return remote
  Note left of client A: Remote addr, Relay server addr
  hbbs ->> client B: 10. Return remote info
  Note right of client B: Remote addr, encrypted PK

  Note over client A, client B: Establish a secure connection key exchange

  client A ->> client B: 11. B's TPK encrypted with B's SK
  client B ->> client B: 12. Decrypt B's TPK, generate, new keypair

  client B ->> client A: 13. Sealed symmetric A's TPK
  client A ->> client A: 14. Decrypt, get symmetric TPK/TSK

  Note over client A, client B: Encrypted communication by using symmetric key

  client B ->> hbbr: 15. Control data
  hbbr ->> client A: 15. Control data
  Note left of client A: Keyboard, Mouse
  client A ->> hbbr: 16. Audio frame, video frame, clipboard
  hbbr ->> client B: 16. Audio frame, video frame, clipboard

Loading

[softyoda]

I steal it from https://cloud.tencent.com/developer/article/1897847

And I draw a simple depoyment diagram to supply some additional information.

Hi, i'm new and would like to get technical-yet-comprehensible info about RustDesk. I'm using parsec to work remotly (fulltime) and i'd wish to know how your servers works. Is the relay server required? What it is purpose ?

[nvm-hvktmm]

hbbs, hbbr meaning?

[akiross]

It's in the server doc: https://github.com/rustdesk/rustdesk-server/blob/master/README.md

• hbbs - RustDesk ID/Rendezvous server
• hbbr - RustDesk relay server

[WaleedMortaja]

@akiross Their job is in the document. However, It is yet not clear how are their names derived. The question is: What does hbbs/hbbr stand for?

[ben221199]

Still no information about the abbrevation meaning of HBB (as in HBBR and HBBS)?