[GH-ISSUE #104] Encryption

gitea-mirror commented

2026-05-05 22:05:40 -06:00

Owner

Originally created by @DrYak on GitHub (Apr 13, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/104

Hi, I switched to this tool as Plasma switched to Wayland and love it.

A few suggestions regarding encryption.

inside lan-mouse

I've noticed that WebRTC-rs have a working implementation of DTLS which would be the cannonical way for input-leap to encrypt UDP streams.

Have you had a look at it? (I am saddly too much of a rust newbie to be of any use making a PR, and even more so with delicate subjects like encryption)

workarounds outside lan-mouse

Until there's proper encryption inside lan-mouse, a few idea for users to hack their own workarounds:

I've noticed dtlspipe which is basically like stunnel but for UDP over DTLS instead of TCP.
There is also the classic approach of using netcat to forward UDP to TCP connection and use SSH forwarding to establish a secure connection. This sacrifice the "spontaneous connect/disconnect" that lan-mouse's UDP offers, but I think SSH tunnels and the port not even open on the laptops' firewalls is about the most secure solution (unless one has the wrong version of XZ 😁 )

Originally created by @DrYak on GitHub (Apr 13, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/104 Hi, I switched to this tool as Plasma switched to Wayland and love it. A few suggestions regarding encryption. ## inside lan-mouse I've noticed that [WebRTC-rs](https://github.com/webrtc-rs/webrtc/) have a working implementation of DTLS which would be the cannonical way for input-leap to encrypt UDP streams. Have you had a look at it? (I am saddly too much of a rust newbie to be of any use making a PR, and even more so with delicate subjects like encryption) ## workarounds outside lan-mouse Until there's proper encryption inside lan-mouse, a few idea for users to hack their own workarounds: - I've noticed [dtlspipe](https://github.com/SenseUnit/dtlspipe) which is basically like stunnel but for UDP over DTLS instead of TCP. - There is also the classic approach of using netcat to forward UDP to TCP connection and use SSH forwarding to establish a secure connection. This sacrifice the "spontaneous connect/disconnect" that lan-mouse's UDP offers, but I think SSH tunnels and the port not even open on the laptops' firewalls is about the most secure solution (unless one has the wrong version of XZ :grin: )

gitea-mirror closed this issue

2026-05-05 22:05:42 -06:00

gitea-mirror commented

2026-05-05 22:05:43 -06:00

Author

Owner

@feschber commented on GitHub (Apr 13, 2024):

WebRTC dtls is in fact exactly what I was planning to use for this.
I will need to rewrite some of the network code in order to use it but I will hopefully get to it in the coming weeks.

@feschber commented on GitHub (Apr 13, 2024): WebRTC dtls is in fact exactly what I was planning to use for this. I will need to rewrite some of the network code in order to use it but I will hopefully get to it in the coming weeks.

gitea-mirror commented

2026-05-05 22:05:44 -06:00

Author

Owner

@DrYak commented on GitHub (Apr 14, 2024):

but I will hopefully get to it in the coming weeks.

That would be extremely cool! I think encryption (or any user-made hack for security) is the last major blocker before more people can start using this as a Synergy replacement (or depending on interests, until Input Leap and/or Waynergy get the bits they need upstreamed into Kwin, portals, etc.)

BTW: I tried packaging your software for my openSuse Tumbleweed. The x86_64 package builds successfully (The i586 variant fails on libadwaita). So I'll be able to easily install accross my machines.

@DrYak commented on GitHub (Apr 14, 2024): > but I will hopefully get to it in the coming weeks. That would be extremely cool! I think encryption (or any user-made hack for security) is the last major blocker before more people can start using this as a Synergy replacement (or depending on interests, until Input Leap and/or Waynergy get the bits they need upstreamed into Kwin, portals, etc.) BTW: I tried [packaging your software](https://build.opensuse.org/package/show/home:dr-yak/lan-mouse) for my openSuse Tumbleweed. The x86_64 package builds successfully (The i586 variant fails on libadwaita). So I'll be able to easily install accross my machines.

gitea-mirror commented

2026-05-05 22:05:45 -06:00

Author

Owner

@feschber commented on GitHub (Apr 15, 2024):

BTW: I tried packaging your software for my openSuse Tumbleweed. The x86_64 package builds successfully (The i586 variant fails on libadwaita). So I'll be able to easily install accross my machines.

I'm not very familiar with OpenSuse but feel free to update the installation instructions if you want that to be included. (you can make a PR).

If Libadwaita does not want to build on i586, you could deactivate the feature for building (cli should still be usable):

cargo build --no-default-features --features wayland,x11,xdg_desktop_portal,libei

Let me know, if that works. I just realized that the gio build dependency is not behind the gtk feature flag.

@feschber commented on GitHub (Apr 15, 2024): > BTW: I tried [packaging your software](https://build.opensuse.org/package/show/home:dr-yak/lan-mouse) for my openSuse Tumbleweed. The x86_64 package builds successfully (The i586 variant fails on libadwaita). So I'll be able to easily install accross my machines. I'm not very familiar with OpenSuse but feel free to update the [installation instructions](https://github.com/feschber/lan-mouse#installation) if you want that to be included. (you can make a PR). If Libadwaita does not want to build on i586, you could deactivate the feature for building (cli should still be usable): ```sh cargo build --no-default-features --features wayland,x11,xdg_desktop_portal,libei ``` Let me know, if that works. I just realized that the gio build dependency is not behind the gtk feature flag.

gitea-mirror commented

2026-05-05 22:05:46 -06:00

Author

Owner

@DrYak commented on GitHub (Apr 15, 2024):

I've tried disabling the GTK Gui, but now the compilation crashes at another point.
Apparently it's going to be complicated to get it working on a non-Tier1 arch.

Well at least the x86_64 works for now.

Looking forward to the upcoming encryption feature.

@DrYak commented on GitHub (Apr 15, 2024): I've tried disabling the GTK Gui, but now the compilation crashes at another point. Apparently it's going to be complicated to get it working on a non-Tier1 arch. Well at least the x86_64 works for now. Looking forward to the upcoming encryption feature.

gitea-mirror commented

2026-05-05 22:05:47 -06:00

Author

Owner

@DrYak commented on GitHub (May 24, 2024):

Do you think you would have time to look into WebRTC-rs DTLS soon~ish?
That's about the last missing critical feature before lan-mouse is "Good Enough™!" for me.

@DrYak commented on GitHub (May 24, 2024): Do you think you would have time to look into WebRTC-rs DTLS soon~ish? That's about the last missing critical feature before lan-mouse is "_Good Enough™!_" for me.

gitea-mirror commented

2026-05-05 22:05:48 -06:00

Author

Owner

@feschber commented on GitHub (May 24, 2024):

I can not realistically give an accurate estimate. But I will try my best to finish it in the coming month.

@feschber commented on GitHub (May 24, 2024): I can not realistically give an accurate estimate. But I will try my best to finish it in the coming month.

gitea-mirror commented

2026-05-05 22:05:49 -06:00

Author

Owner

@d4nshields commented on GitHub (May 24, 2024):

Adding security is a fantastic idea. Whether through the WebRTC stack or through some other library, DTLS would indeed be a great solution for securing UDP-based connections while maintaining the performance benefits crucial for our use case.

I've reviewed the network handler module in the source code, and I believe there's a well-defined structure that could facilitate the integration of DTLS. To further enhance this, I was thinking of adding DTLS as an optional feature through a command-line switch, giving users flexibility based on their security needs and performance considerations.

As a current user of the open-source/free fork of Synergy, I am enthusiastic about the potential robustness this solution can bring. Adding security is an absolute must-have for me. I'd love to offer my assistance with this implementation. Whether it's rewriting parts of the network code, testing the new features, or contributing to documentation, I'm eager to contribute and support this initiative in any way I can.

@d4nshields commented on GitHub (May 24, 2024): Adding security is a fantastic idea. Whether through the WebRTC stack or through some other library, DTLS would indeed be a great solution for securing UDP-based connections while maintaining the performance benefits crucial for our use case. I've reviewed the network handler module in the source code, and I believe there's a well-defined structure that could facilitate the integration of DTLS. To further enhance this, I was thinking of adding DTLS as an optional feature through a command-line switch, giving users flexibility based on their security needs and performance considerations. As a current user of the open-source/free fork of Synergy, I am enthusiastic about the potential robustness this solution can bring. Adding security is an absolute must-have for me. I'd love to offer my assistance with this implementation. Whether it's rewriting parts of the network code, testing the new features, or contributing to documentation, I'm eager to contribute and support this initiative in any way I can.

gitea-mirror commented

2026-05-05 22:05:49 -06:00

Author

Owner

@DrYak commented on GitHub (Jul 31, 2024):

@feschber: Any idea when you'll attack work on that feature?

@DrYak commented on GitHub (Jul 31, 2024): @feschber: Any idea when you'll attack work on that feature?

gitea-mirror commented

2026-05-05 22:05:50 -06:00

Author

Owner

@feschber commented on GitHub (Jul 31, 2024):

I have a deadline at University coming up tomorrow, will hopefully have more time on hand after that.
Will probably also tackle #164 at the same time and make the whole thing a client server model.

@feschber commented on GitHub (Jul 31, 2024): I have a deadline at University coming up tomorrow, will hopefully have more time on hand after that. Will probably also tackle #164 at the same time and make the whole thing a client server model.

gitea-mirror commented

2026-05-05 22:05:51 -06:00

Author

Owner

@feschber commented on GitHub (Sep 4, 2024):

to give an update:

I've got things working with selfsigned keys! 🎉

There are some things I still need to figure out though:

connection probing
automatic ip switching
replying to the correct connection (currently events simply sent to the server hosted on the other device)

Regardless: This text was typed over a secure lan-mouse connection 😃

@feschber commented on GitHub (Sep 4, 2024): to give an update: I've got things working with selfsigned keys! :tada: There are some things I still need to figure out though: - connection probing - automatic ip switching - replying to the correct connection (currently events simply sent to the server hosted on the other device) Regardless: This text was typed over a secure lan-mouse connection :smiley:

gitea-mirror commented

2026-05-05 22:05:51 -06:00

Author

Owner

@jonstelly commented on GitHub (Sep 10, 2024):

Nice work! I've been looking forward to switching over to lan-mouse but was waiting for encryption. I'm guessing it's the encryption branch? - https://github.com/feschber/lan-mouse/compare/main...encryption

I'm eager to start testing this, will start playing around with the arch aur package to get it built with new dependencies

@jonstelly commented on GitHub (Sep 10, 2024): Nice work! I've been looking forward to switching over to lan-mouse but was waiting for encryption. I'm guessing it's the encryption branch? - https://github.com/feschber/lan-mouse/compare/main...encryption I'm eager to start testing this, will start playing around with the arch aur package to get it built with new dependencies

gitea-mirror commented

2026-05-05 22:05:52 -06:00

Author

Owner

@feschber commented on GitHub (Sep 10, 2024):

I'm guessing it's the encryption branch? - main...encryption

Yes, thats correct. It's not quit ready yet, I rewrote quite a few things to fit into the client-server model so be prepared to get your cursor stuck ;). But the basic functionality is working so far.

@feschber commented on GitHub (Sep 10, 2024): > I'm guessing it's the encryption branch? - [main...encryption](https://github.com/feschber/lan-mouse/compare/main...encryption) Yes, thats correct. It's not quit ready yet, I rewrote quite a few things to fit into the client-server model so be prepared to get your cursor stuck ;). But the basic functionality is working so far.

gitea-mirror commented

2026-05-05 22:05:52 -06:00

Author

Owner

@jonstelly commented on GitHub (Sep 10, 2024):

Got it built and running. I did get the cursor stuck at first, created config files on both machines and now it's up and running. wireshark showed encrypted traffic.

The aur package ( https://aur.archlinux.org/packages/lan-mouse-git ) didn't build correctly but I built directly from git clone and that worked. I'll work on the AUR package to see if I can figure out what's going on (not a rust guy but this is a good excuse to learn a bit)

@jonstelly commented on GitHub (Sep 10, 2024): Got it built and running. I did get the cursor stuck at first, created config files on both machines and now it's up and running. wireshark showed encrypted traffic. The aur package ( https://aur.archlinux.org/packages/lan-mouse-git ) didn't build correctly but I built directly from git clone and that worked. I'll work on the AUR package to see if I can figure out what's going on (not a rust guy but this is a good excuse to learn a bit)

gitea-mirror commented

2026-05-05 22:05:52 -06:00

Author

Owner

@feschber commented on GitHub (Sep 10, 2024):

@jonstelly the package does not build currently because I moved the svg.
I will fix that.

@feschber commented on GitHub (Sep 10, 2024): @jonstelly the package does not build currently because I moved the svg. I will fix that.

gitea-mirror commented

2026-05-05 22:05:53 -06:00

Author

Owner

@feschber commented on GitHub (Sep 10, 2024):

should be fixed now

@feschber commented on GitHub (Sep 10, 2024): should be fixed now

gitea-mirror commented

2026-05-05 22:05:53 -06:00

Author

Owner

@DrYak commented on GitHub (Sep 17, 2024):

That's super cool developments! Thanks for your work!

BTW:
I was wondering, have you given though to emoji verification (like Riot does) as a way to establish a verified encrypted link?

@DrYak commented on GitHub (Sep 17, 2024): That's super cool developments! Thanks for your work! BTW: I was wondering, have you given though to [emoji verification (like Riot does)](https://www.uhoreg.ca/blog/20190514-1146) as a way to establish a verified encrypted link?

gitea-mirror commented

2026-05-05 22:05:54 -06:00

Author

Owner

@feschber commented on GitHub (Sep 17, 2024):

Yeah I want to have some sort of 'trust on first use' model, maybe similar to ssh or via emoji verification. However I'm not 100% sure how to do it yet.

Right now I'm side-stepping the authenticity problem a bit to get the rest working first.

@feschber commented on GitHub (Sep 17, 2024): Yeah I want to have some sort of 'trust on first use' model, maybe similar to ssh or via emoji verification. However I'm not 100% sure how to do it yet. Right now I'm side-stepping the authenticity problem a bit to get the rest working first.

gitea-mirror commented

2026-05-05 22:05:54 -06:00

Author

Owner

@feschber commented on GitHub (Sep 27, 2024):

I do now have an ssh-like fingerprint based authentication scheme in place, I think this should be easy enough to work with.

@feschber commented on GitHub (Sep 27, 2024): I do now have an ssh-like fingerprint based authentication scheme in place, I think this should be easy enough to work with. ![image](https://github.com/user-attachments/assets/3c284f60-ad5d-49fc-869b-7f391a463a9d) ![image](https://github.com/user-attachments/assets/eed54a32-a146-4c80-b6bd-94cc44d5f940)

gitea-mirror commented

2026-05-05 22:05:55 -06:00

Author

Owner

@feschber commented on GitHub (Sep 27, 2024):

Main blocker right now is the not yet finished one-way control logic.

@feschber commented on GitHub (Sep 27, 2024): Main blocker right now is the not yet finished one-way control logic.

gitea-mirror commented

2026-05-05 22:05:55 -06:00

Author

Owner

@nbolton commented on GitHub (Sep 27, 2024):

Did you see what Input Leap did with this? Quite neat. Shows a nice pattern which is easier to visualize than a raw SHA fingerprint. I plan on copying the idea in Deskflow.

@nbolton commented on GitHub (Sep 27, 2024): Did you see what Input Leap did with this? Quite neat. Shows a nice pattern which is easier to visualize than a raw SHA fingerprint. I plan on copying the idea in Deskflow.

gitea-mirror commented

2026-05-05 22:05:55 -06:00

Author

Owner

@feschber commented on GitHub (Sep 27, 2024):

@nbolton yeah that is something I'm planning to do for an "accept this connection" prompt.
Definitely an upgrade over the raw sha256 hash (even though I find hash values somewhat cool too look at 😆 ).

@feschber commented on GitHub (Sep 27, 2024): @nbolton yeah that is something I'm planning to do for an "accept this connection" prompt. Definitely an upgrade over the raw sha256 hash (even though I find hash values somewhat cool too look at :laughing: ).

gitea-mirror commented

2026-05-05 22:05:56 -06:00

Author

Owner

@jonstelly commented on GitHub (Oct 2, 2024):

This is looking great, I've been running the encryption branch across a couple linux machines. I just updated to pick up the fingerprint checks.

If I configure the fingerprints on each machine using the UI, everything works. When I try to add them to the config.toml like:

[authorized_fingerprints]
other = "aa:bb:..."

It looks like lan-mouse picks up the configuration, the GUI shows the configured fingerprints, but the mouse doesn't transition from one machine to the other and I get "accept: expected and actual verify data does not match"

Looking really good though, keep up all the great work!

@jonstelly commented on GitHub (Oct 2, 2024): This is looking great, I've been running the encryption branch across a couple linux machines. I just updated to pick up the fingerprint checks. If I configure the fingerprints on each machine using the UI, everything works. When I try to add them to the config.toml like: ``` [authorized_fingerprints] other = "aa:bb:..." ``` It looks like lan-mouse picks up the configuration, the GUI shows the configured fingerprints, but the mouse doesn't transition from one machine to the other and I get "accept: expected and actual verify data does not match" Looking really good though, keep up all the great work!

gitea-mirror commented

2026-05-05 22:05:56 -06:00

Author

Owner

@feschber commented on GitHub (Oct 2, 2024):

This is looking great, I've been running the encryption branch across a couple linux machines. I just updated to pick up the fingerprint checks.

If I configure the fingerprints on each machine using the UI, everything works. When I try to add them to the config.toml like:
[authorized_fingerprints]
other = "aa:bb:..."
It looks like lan-mouse picks up the configuration, the GUI shows the configured fingerprints, but the mouse doesn't transition from one machine to the other and I get "accept: expected and actual verify data does not match"

Looking really good though, keep up all the great work!

You have the configuration backwards. It may seem a bit counterintuitive, but it should be "aa:bb:..." = "description" idea being that the fingerprint is the unique key but a description can be identical.

@feschber commented on GitHub (Oct 2, 2024): > This is looking great, I've been running the encryption branch across a couple linux machines. I just updated to pick up the fingerprint checks. > > If I configure the fingerprints on each machine using the UI, everything works. When I try to add them to the config.toml like: > > ``` > [authorized_fingerprints] > other = "aa:bb:..." > ``` > > It looks like lan-mouse picks up the configuration, the GUI shows the configured fingerprints, but the mouse doesn't transition from one machine to the other and I get "accept: expected and actual verify data does not match" > > Looking really good though, keep up all the great work! You have the configuration backwards. It may seem a bit counterintuitive, but it should be `"aa:bb:..." = "description"` idea being that the fingerprint is the unique key but a description can be identical.

gitea-mirror commented

2026-05-05 22:05:56 -06:00

Author

Owner

@feschber commented on GitHub (Nov 9, 2024):

It took a lot longer than I anticipated but its finally here!

@feschber commented on GitHub (Nov 9, 2024): It took a lot longer than I anticipated but its finally here!

gitea-mirror commented

2026-05-05 22:05:58 -06:00

Author

Owner

@DrYak commented on GitHub (Feb 10, 2025):

Do you have an ETA when this support will be in a tagget release (i.e.: are you planning to release v0.11.0 soonish?)
I've successfully tested it in self-compiled master.

@DrYak commented on GitHub (Feb 10, 2025): Do you have an ETA when this support will be in a tagget release (i.e.: are you planning to release v0.11.0 soonish?) I've successfully tested it in self-compiled master.

gitea-mirror commented

2026-05-05 22:05:59 -06:00

Author

Owner

@feschber commented on GitHub (Feb 12, 2025):

Do you have an ETA when this support will be in a tagget release (i.e.: are you planning to release v0.11.0 soonish?)
I've successfully tested it in self-compiled master.

I have not done a release because the encryption is a little cumbersome to use without a config file so I wanted to first add some save configuration option.

@feschber commented on GitHub (Feb 12, 2025): > Do you have an ETA when this support will be in a tagget release (i.e.: are you planning to release v0.11.0 soonish?) > I've successfully tested it in self-compiled master. I have not done a release because the encryption is a little cumbersome to use without a config file so I wanted to first add some save configuration option.

gitea-mirror commented

2026-05-05 22:05:59 -06:00

Author

Owner

@DrYak commented on GitHub (Feb 18, 2025):

Okay, thanks for the answer, and good luck with your task!

BTW big thanks for all your work: for me lan-mouse has reached the "good enough to cover my needs" state.

@DrYak commented on GitHub (Feb 18, 2025): Okay, thanks for the answer, and good luck with your task! BTW big thanks for all your work: for me lan-mouse has reached the "*good enough to cover my needs*" state.

gitea-mirror commented

2026-05-05 22:05:59 -06:00

Author

Owner

@feschber commented on GitHub (Feb 18, 2025):

Thank you! Great to hear.

@feschber commented on GitHub (Feb 18, 2025): Thank you! Great to hear.

gitea-mirror referenced this issue

2026-05-05 22:15:14 -06:00

[PR #43] [MERGED] Background service #250