Encryption

[DrYak]

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 😁 )

[feschber]

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.

[DrYak]

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.

[feschber]

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.

[DrYak]

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]

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.

[feschber]

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

[d4nshields]

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.

[DrYak]

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

[feschber]

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]

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 😃

[jonstelly]

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? - 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

[feschber]

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.

[jonstelly]

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)

[feschber]

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

[feschber]

should be fixed now

[DrYak]

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?

[feschber]

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]

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

[feschber]

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

[nbolton]

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.

[feschber]

@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 😆 ).

[jonstelly]

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!

[feschber]

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.