# Synergy

### Feature #12 - Encryption

Status:
Fixed
Priority:
Normal
Assignee:
Category:
System
Target:
1.4.11
Created by:
Created on:
27 Feb 2009
Updated by:
Updated on:
12 Apr 2013 03:54
Platform:
Various
gc-3
Redmine ID:
13

• Related to: Bug #3572 - Mac caps lock causes disconnect
• Related to: Bug #3565 - Encryption fails when typing fast (Invalid message from client)
• Duplicated by: Feature #721 - Secure Communications
• Duplicated by: Feature #751 - SSL Support

Problem: Anyone using a packet sniffer can easily record keystrokes sent over the network by Synergy.

Solution: Implement encryption which is on by default, but can be turned off.

#1

27 Feb 2009: Issue Importer wrote a comment.

Google user: aidin.fanni

Meant to enter this as an enhancement request, not a defect. Failed miserably.

#2

2 Mar 2009: Issue Importer wrote a comment.

Google user: sorin.sbarnea

At least please vote for this
This may speedup the adding of the edit feature to the bug summary.

2 Mar 2009: Issue Importer changed Status.

New Accepted

2 Mar 2009: Issue Importer changed Title.

Tunnel the synergy connection thru SSL.

2 Mar 2009: Issue Importer changed Priority.

Normal Low

#3

5 Mar 2009: Issue Importer wrote a comment.

Google user: minupla

I agree on this one, and would like to see it have a higher priority. Yes, I tunnel
over ssh, but it's a pain, and I expect the vast majority of users don't bother,
potentially unwittingly exposing their personal data to interception, since there's
no clear warning during installation.

#4

15 Mar 2009: Issue Importer wrote a comment.

Google user: sorin.sbarnea

15 Mar 2009: Issue Importer changed Found in ver.

1.3.2

#5

23 May 2009: Issue Importer wrote a comment.

Google user: sorin.sbarnea

#6

23 May 2009: wrote a comment.

-Missing comment-

#7

23 May 2009: wrote a comment.

-Missing comment-

#8

23 May 2009: wrote a comment.

-Missing comment-

23 May 2009: Issue Importer changed Target.

?

#9

10 Jun 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

10 Jun 2009: Issue Importer changed Title.

Improve network security with encryption with SSL

#10

4 Jul 2009: Issue Importer wrote a comment.

Google user: edw...@carrel.org

I have started looking into this some, and have a number of implementation level
questions I'd like to ask everyone listening on this ticket, so I can get something
close to what everyone wants. Here are a few options I can think up just off the top

1. User-distributed key

Positives: Wow, really easy. Either scp(1) the keyfile or sneakernet it across to the
other host once created. And we don't need to worry as much about trusting the
authenticity of the key, because we know exa
ctly where it came from. Implementation will not be hard either, just have the user
either pass a key location or put it in some predetermined place.
Negative: Requires legwork to get the keys moved around.

1. Diffie-Hellman key exchange.

Positives: Easy to implement. Requires little user input save setting a flag that
says 'encrypt this connection'.
Negatives: All you get is encryption. There is absolutely no authentication; you have
no idea if the server you are talking to is the one you want to talk to. There's no
protection from man-in-the-middle attac
ks, either. But, as long as people are using all of this on trusted networks, this
might not be such a big deal.

1. Server holds a public/private keypair, perhaps bound up in a certificate, perhaps
even signed by a particular Certificate Authority (CA).
Positives: a stronger sense of authentication, especially when provided a certificate
signed by a CA the user trusts (perhaps their own CA?). The client holds the CA
certificate as well, and verifies that the
CN record within the certificate matches the host name the user is connecting to.
Negatives: Even this is not perfect, you have to have a hostname for the server, and
the DNS infrastructure returning that host address has to be something you have
control over. And there's a trust relationsh
ip in all of these certificates that may not be valid. This will require the most
implementation work as well, which might not be worth the effort.

2. Other ideas?
The ROT-13 idea proposed by a poster on the discussion group won't really buy us a
whole lot, since much of the data we transmit is numeric data specifying the code of
pressed keys or the location of the point
er on screen. If we're going to have encryption, presumably we are doing so because
we are worried about people sniffing the wire; if they can do that, odds on they know
ROT-13 when they see it.

So, options abound, and I probably haven't enumerated them all. Depending on what the
plan is, we'll want to probably talk about implementation specifics (libraries, etc.)

#11

5 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

+1 for User-distributed key, but it should be optional of course, for users who
aren't savy enough to copy files over the network (or don't care about encryption).

#12

5 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#13

5 Jul 2009: Issue Importer wrote a comment.

Google user: syed.a...@gilani.eu

I don't know if it is what you mean with 1. but i would prefer a pre shared key. Just
let the user specify a Password in the config files on every Server/Client and encrypt
the Connection with it. It the easiest Setup for not so experienced Users.

5 Jul 2009: Issue Importer changed Title.

Improve network security by using encryption

#14

10 Jul 2009: Issue Importer wrote a comment.

Google user: Jason.Donenfeld

You're probably not going to design a better or as expansive encryption system as
that offered by OpenSSH. So, why not just build an option into synergy which
automatically sets up synergy to tunnel through SSH or to connect through SSH.

synergys --local or synergy --ssh or synergys -a 127.0.0.1
configures synergy to only listen for connections locally. then,

synergyc --ssh myHost
connects to myHost via SSH, forwards the ports using SSH's port forwarding
capability, and the connects locally so it's tunneled through SSH

OR

We could go the route of rsync: connecting with the SSH options spawns a process on
the other machine and forwards all data pouring out of that process.

#15

10 Jul 2009: Issue Importer wrote a comment.

Google user: edw...@carrel.org

@Jason:

The thought of relying on SSH did cross my mind; for a number of months, this is how
I encrypted the stream between server and the client I set up. However, it felt very
much like a stop-gap, and I wasn't fond of it as a long-term general solution.
Allowing it as an option for people who know what they are doing might not be a bad idea.

Forcing people to rely on OpenSSH, however, I worry about. OpenSSH relies on the
authentication mechanism of the underlying operating system. The user involved would
have to have control over that and know how to control it, which might not be the
case. We'll have to build a way for them to securely provide their password through
us into OpenSSH, so that the tunnel can be built. Or they could rely on a key pair,
but I can't imagine every user of synergy knowing how to do that, or having the
patience to learn. Even the key pair discussion we're having here is a bit troubling
to work out for highest ease-of-use.

And we'd have to rely on one of the two hosts running an SSH daemon, which may not
always be the case. That is, unless we want to force the users to run one, but that
seems a bit rude.

And none of this will work with Windows, unless the user has Cygwin installed and we
can find sshd running, or an ssh client.

Hence, I think it is worthwhile to present users with an alternative where synergy
handles encryption and authentication itself. As for designing a better encryption
scheme, I hadn't planned on doing so: OpenSSL is one option, Botan is another, and
I'm sure there are others that people can suggest.

So yeah, I would be in favor of building functionality that allows for a one flag
initiation of both an SSH tunnel and a synergy connection for those who want that
sort of convenience, but I'm not in favor of it being the only option. But feel free
to shout me down if my reasoning seems off base; an invitation extended to everyone
else listening on this ticket as well. :-)

The remote launching of synergy is an interesting idea as well. I'll give my brain a
bit of time to chew on that; someone else might have a response in the meantime.

#16

10 Jul 2009: Issue Importer wrote a comment.

Google user: minupla

I think the best and most transparent option is probably SSL. If the user has the
appropriate certs already (eg: in our office environment everything is signed by an
enterprise CA) the connection is transparent. If it's a first connect, prompt the
user to verify the cert. After that, have the user set a password on each end for
authentication.

#17

13 Jul 2009: Issue Importer wrote a comment.

Google user: aidin.fanni

I also think that SSL is most probably the way to go.

I believe you should have two options to pick from.

First would be TLS connection between server and client and password authentication
on server side. This posses the problem of saving the password somewhere safe I guess
and more coding.

Other would login with keys. Each client generates a key, (with or without password)
specific for itself, you copy the public key to the server with a USB stick or thru
SSH if you trust your network and you use similar process as a SSH connection with
trusted key to login to server.

#18

13 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

The problem is OpenSSH requires Cygwin to run on Windows (so I'm told), so something
tells me that we should avoid depending on Cygwin. Lets take Putty as an example.
It's an SSH client at least, and it doesn't require Cygwin. Can Putty work as an SSH
server, if so then we should look at the Putty source code...

#19

15 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Hi guys, I only just found this split off of synergy today, I have actually written a
AES encryption patch for synergy, which has a cross platform library between linux
and windows, tho ive only tested it with linux atm, with a hardcoded key, tho it
works fine, there are a couple bugs i have to work out, but if you guys are keen i
can submit it to here once i clean it up

#20

16 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

ve...@gen-x.co.nz,

Thanks, yes, please submit your patch, and I will deploy it to a new branch so that
others can test and critique it before we integrate it into the main branch.

Nick

#21

16 Jul 2009: Issue Importer wrote a comment.

Google user: edw...@carrel.org

@venom: I'd been hacking on this some myself, but would be interested to see what you
have to avoid further duplicated effort.

In the mean time, a couple of questions:

1. Which library are you relying on for supporting AES? What other platforms does it
support?

2. What does "hard coded key" mean? Is this akin to defining a key within the
codebase somewhere as a statically defined array? Not that it is a bad first step.
We'll probably be able to incorporate some of the work I'm doing to make key
assignment more flexible. :-)

Anyway, thanks, and looking forward to your patch. :-)

#22

16 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Hi there,

1) Mcrypt, as This is most common in *nix systems including OSX, its widely used by
php as well, and there are ports for windows for it.

2) Rather then reading a pre-shared key from the config, i wrote it directly into the
code for testing purposes.

I'm currently using RIJNDAEL (aka AES) with 128bit , and using CFB mode for the block
cipher
("http://en.wikipedia.org/wiki/Blockciphermodesofoperation#Cipherfeedback.28CFB.29":http://en.wikipedia.org/wiki/Blockciphermodesofoperation#Cipherfeedback.28CFB.29 ),
which is best for this type of data transfer , if it was only one way I'd go with CBC
or something like that.

I encrypt each keypress because each keypress is a packet, and i simply encrypt the
payload and decrypt it on the reverse side.

TBH, I wrote this back in January and haven't touched more on it, I had it all
working but I got an occasional memory leak that I needed to address, so I will
download your synergy , and merge it in and do a diff patch for you guys to have a
look at, and you guys can give me your thoughts and ideas

#23

21 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Hi guys, just giving you an update to where I'm at with the port.

Ok well I have ported the code today, wasnt hard as nothing in that section had
changed, but then i remembered the bug I had, which I'm currently working on it atm.

Basicly the bug im having is after a client disconnects then reconnects to the
server, even tho the encrypted data transmitted matches, on the client end it decodes
incorrectly, I'm trying to work out if its a problem with the IV and its getting
corrupted in memory, or something is going on, so once thats sorted I'm all good.

But yea, this is only affects clients reconnecting.

#24

21 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Hrm, I may have spoke too soon, I discovered if i leave it for like 5-10 seconds the
encryption seems to sort itself out and reestablish itself correctly.

#25

22 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Nice! Sounds like you're making progress. Perhaps you could send us a patch?

#26

22 Jul 2009: wrote a comment.

-Missing comment-

#27

22 Jul 2009: wrote a comment.

-Missing comment-

27 Jul 2009: Issue Importer uploaded a file.

ugly_patch.patch - 27 Aug 2010 23:32

#28

27 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Hi guys, Im sorry about the delay, I been busy with work and well.. having a life to
be honest, This is my old ugly code before I started doing some proper work on it,
How ever I've having issues with the new code I've written for you with calls
functions inside an object rather then have it embedded directly in CArch.cpp,

If you have vc++ grab the follow and slap it inside a mcrypt dir inside lib/arch,
oviously if your done a checkout you will need to add the libmcrypt.lib to the
library in vc++ for libsynergy,client,launcher and server,in linux just modify your
Makefiles after you have done a configure, you will need to modify the above dir's i
listed for vc++ for linux/osx

"ftp://mcrypt.hellug.gr/pub/crypto/mcrypt/libmcrypt/win32/libmcrypt-2.5.3-win32.zip":ftp://mcrypt.hellug.gr/pub/crypto/mcrypt/libmcrypt/win32/libmcrypt-2.5.3-win32.zip

Anyways I know its a nasty patch I have written a better one, but Ive got another bug
im working on for the new cleaner patch, this is a more, proof of concept patch.

(sorry bout my double posting if you see it, i attached the CArch.cpp by mistake lol)

#29

27 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

One thing that will need to be addressesed is that, every time the server is started
the IV is ment to be randomized and pushed out to the client (atm I have it all
static), the key is ment to kept
private, the iv is counted as the public, it should change every time the server is
initialized and passed to the client when it connects so it knows what the new IV is,
but the way that synergy net code is, its a f**king mess to be honest.

Anyways, more todo's and ill release a proper cleaner patch for the encryption object
shortly, just busy with work atm..

-- VeNoMouS

#30

27 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Jesus, I reread what i typed above, ME SPEAK ENGLAND GOOD!!!!! time for a coffee i
think, man wtf.... english is my primary language shakes head

#31

28 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Haha, ok I'll try that out on a branch and let you know how I get on. I will test on
Linux, Mac and Windows.

#32

28 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

I've tested (server was linux) client linux, and client windows xp

#33

30 Jul 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Nick, How did you go? Any issues?

#34

30 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

I actually haven't gotten round to it yet. It's been a bit of a hectic week for me, so
I haven't spent as much time on Synergy+ as I usually do. I'll let you know when I get
a spare half day - should be early next week some time :)

#35

6 Aug 2009: Issue Importer wrote a comment.

Google user: oct2274

Does anyone know how Input Director handles encryption? Unfortunately Input Director
only works between Windows hosts, that is why I happened across this project. I
typically use Windows and Linux but need encryption.

#36

6 Aug 2009: Issue Importer wrote a comment.

Google user: palkina1

In short, !!RTFM!!

"http://www.inputdirector.com/faq.html#82":http://www.inputdirector.com/faq.html#82

A. 8.2 What ciphers does Input Director support?

Input Director currently offers the Advanced Encryption System (AES) cipher. If you
accommodated.

A. 8.3 Which encryption library does Input Director use?

Input Director uses the OpenSSL library version 0.9.8g

10 Aug 2009: Issue Importer changed Status.

Accepted InProgress

10 Aug 2009: Issue Importer changed Priority.

High Normal

10 Aug 2009: Issue Importer changed Status.

InProgress Accepted

#37

10 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#38

10 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#39

10 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

I'm busy with fixing issues with the build system, so I don't have time to create the
branch, apply the patch, test, etc. I will do this as soon as our new build system is
working correctly.

Thanks for waiting, we appreciate your contribution.

13 Aug 2009: Issue Importer changed Status.

Accepted InProgress

#40

13 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#41

13 Aug 2009: wrote a comment.

-Missing comment-

#42

13 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

ve...@gen-x.co.n,

I have committed your patch to the repository under a new branch ("/p/synergy-plus/source/detail?r=0dbec5f3dc":revision 0dbec5f3dc ).
I have also applied some changes so that the code complies with our code styling
guidelines, plus a few other tweaks ("/p/synergy-plus/source/detail?r=a7c5329de9":revision a7c5329de9 )

Does libmcrypt require Cygwin? If so, then we may have to explore other avenues like
OpenSSL.

#43

13 Aug 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Ah yup, yea in the second version of the code i wrote, i replaced those printf's with
clog myself...

Re: Cygwin compiling mcrypt.

Hrm, I'm not to sure , as I used the precompiled dll's for the windows side, which
are all over the net to d/l, I will look into it tomorrow at work, as its 3am atm.

#44

13 Aug 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

FYI: it seems crypto++ may be compatible with mcrypt (as it does aes with Rijndael)
and it also handles CFB block ciphers, and crypto++ is vc++ friendly, so i could
write in a ifdef win32 using crypto++ or rewrite the whole thing to crypto++..

"http://www.cryptopp.com/":http://www.cryptopp.com/

Anyway, work for tomorrow or the weekend.

ME BED, SLEEP 3:15am!!!

#45

13 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#46

13 Aug 2009: wrote a comment.

-Missing comment-

#47

14 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Oh, and I forgot to mention. You may find our code style guide helpful.

I always keep it open when I'm working on our source code.

#48

14 Aug 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Everyone reading this thread, After talking to nick , I realised I cocked up on the
mcrypt urls

# They should be

"http://files.edin.dk/php/win32/mcrypt/dev/lib/libmcrypt.dll":http://files.edin.dk/php/win32/mcrypt/dev/lib/libmcrypt.dll
"http://files.edin.dk/php/win32/mcrypt/dev/lib/libmcrypt.lib":http://files.edin.dk/php/win32/mcrypt/dev/lib/libmcrypt.lib

# "http://files.edin.dk/php/win32/mcrypt/dev/include/mcrypt.h":http://files.edin.dk/php/win32/mcrypt/dev/include/mcrypt.h

Not the previous site I posted, Sorry...

#49

14 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Just added those to a contrib dir, and updated the Windows code a bit. I guess
they're win32, so may have problems when we try this on win64, but we'll see...

Also, I've got this all to work on Windows now (as well as Linux), but for some
reason on my Mac, even after installing the MacPorts libmcrypt package, -lmcrypt
doesn't work:

... weird.

Anyway, if anyone wants to take this out for a spin, the commands are:

hg pull
hg up patch-issue-3-a
hm dest
hm b

Note: Don't confuse hm with hg (I knew we should have picked a better name).

16 Aug 2009: Issue Importer changed Status.

InProgress ?

#50

16 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#51

16 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Should this be milestone M1? It seems quite popular... It doesn't seem "essential"
though. How badly do people want this and why?

#52

16 Aug 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Well, we still need to do ALOT work on it, like the IV key exchange, and the ability
to store the private key, and also put it into the gui && config, and also perhaps
split it out to its object file like I was attempting too.

I have no issues to set this as a milestone as long as it stays active.

What sort of completion/roll out date you looking for?

#53

16 Aug 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Hmm, I think M2 is fine. Despite it being a very popular feature, I think setting to M1
would just push it back too far. VeNoMouS, see how you get on though; if you can get
this nice and polished for M1, then we'll release it at this point.

Let me know when you have a new patch, so I can take this off hold! :)

#54

1 Sep 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Yo nick,

Sorry have'nt had a chance to do any work on the patch, been busy, Will try to get
some of this done today.

#55

1 Sep 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

No worries. I've been busy my self (I'm in the middle of moving house). Hope you make
some progress!

#56

27 Oct 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Ok... OK OK!!!!!! So i've been lazy lately... lol just remembered I still have this
to do...

I'm sure I can find some time to get this finished..

#57

28 Oct 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

your fix is well anticipated. I think Linux people will be happy to replace SSH as a
means for S+ encryption, and also as a Windows user I will look forward to it.

#58

29 Oct 2009: Issue Importer wrote a comment.

Google user: docwhat

I was thinking about the user interface for this and I was thinking that this would be good:
* The server generates a public/private key.
* When the client connects the first time it pops up a dialog printing the fingerprint for the server's key on
both the server and the client.
* On the client, the user is asked to confirm the fingerprint.
* If accepted, then the key is saved and the user is only bothered if it changes on the server.

Of course, for savvy users, they can pre-distribute the key via scp or something.

Ciao!

#59

13 Nov 2009: Issue Importer wrote a comment.

Google user: mattd00d82

Is this on Hold? Seems like a very important feature if you ask me.

#60

13 Nov 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Our friend VeNoMouS from NZ was working on this for a while, but I haven't heard from
him in a while ;)

#61

13 Nov 2009: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Its because i procrastinate too much.....

I promise Ill do work on it over the next week or two... !!!!PROMISE!!!!!

I'll make it #1 on my todo.

#62

10 Mar 2010: Issue Importer wrote a comment.

Google user: richardw...@gmail.com

Is this put on hold indefinieatly or just until someone bothers to pick it up?

12 Mar 2010: Issue Importer changed Status.

? PatchesWelcome

#63

12 Mar 2010: Issue Importer wrote a comment.

Google user: nick.bolton.uk

richardwiden, patches welcome!

#64

8 Apr 2010: Issue Importer wrote a comment.

Google user: Andrew.Johnson.H

@nick.bolton,
can you provide the branch location with the latest progress? I would like to take a
look as well but am not quite sure where this was left.

#65

2 May 2010: Issue Importer wrote a comment.

Google user: BostonVaulter

Hi Andrew, your best branch would either be master or edge. Most of the developers are basing our work directly
off of master at this time.

#66

3 May 2010: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

lol man im a lazy bastard arnt I :P...

is it worth me picking this backup?

#67

3 May 2010: Issue Importer wrote a comment.

Google user: stevenhoneyman

#68

3 May 2010: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Alright I haven't really been much lately except google map harvesting (long story)

So... I guess I can pick this backup, perhaps do a little rewrite of the whole
encryption routine I did.

#69

3 May 2010: Issue Importer wrote a comment.

Google user: Andrew.Johnson.H

Let me know if you need help with anything.

#70

9 May 2010: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Nick, can you get ahold of me on irc or sonmething, need to discuss some things with you.

#71

9 May 2010: Issue Importer wrote a comment.

Google user: VeNoMouS...@gmail.com

Ok so I might have a standalone way to do the aes encryption instead of using the
mcrypt library, I borrowed the rijndael from the obsd kernel, but I'm going to setup a
key exchange when the client connects to the server, passwords will be a max of 16
chars (assuming we stay with 256bit) and we will generate a 16 char temp session
password and mash it into the key, this way the keys presses can't be predicted.

perhaps we need a key rotation but thats a whole different can of worms, anyway i will
incorporate this into the code and give it a test.

5 Jun 2010: Issue Importer changed Target.

? ?

5 Jun 2010: Issue Importer changed Assignee.

2

#72

5 Jun 2010: Issue Importer wrote a comment.

Google user: nick.bolton.uk

venom, hey, I've been away for a while, but I'm back (you may have noticed a flurry of
activity over the last week). You may want to send a quick email to the dev mailing

#73

5 Jun 2010: Issue Importer wrote a comment.

Google user: nick.bolton.uk

#74

6 Jun 2010: Issue Importer wrote a comment.

Google user: edw...@carrel.org

@venom: I worry about us throwing in stand-alone code that we'll have to maintain to
do encryption work. I don't know about how versed you are in the world of encryption,
but I've gathered from others who are that there is just an incredible amount of
things that, if done slightly wrong, make the encryption completely worthless.

What do you see our own standalone AES-256 implementation buying us?

@everyone: Two things we have not been discussing at all in this conversation is
authorization and authentication. Along with the encryption, we should think about
at least appending an HMAC based on the key-pairs agreed on by the client and
server.

So far, we've been discussing encrypting the data, blasting it over the wire, and
then decrypting on the other side and trusting whatever comes out. Granted, for the
average naive bit-flipper this will be complete garbage, but it would be nice to know
it is garbage before we decrypt and try to act on it.

Furthermore, if someone does find a way to change encrypted packets in a less random
way, we'll have an added layer of protection to catch that happening, and not act on

This would also buy us authentication, if both client and server are operating off of
pre-shared keys. If we allow for on-the-fly key generation, we'll need a different
authentication layer.

#75

6 Jun 2010: Issue Importer wrote a comment.

Google user: BostonVaulter

edward: I really agree about not wanting to be using AES directly, I find that this blog post sums up my thoughts
very well.

"http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-":http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-
doing.html

Perhaps we can do some sort of two phase approach, do either encryption or authentication first?

#76

7 Jun 2010: Issue Importer wrote a comment.

Google user: nick.bolton.uk

Created a new trunk for experimental encryption code:

Anyone is welcome to commit changes. Hack away!

#77

7 Jun 2010: Issue Importer wrote a comment.

Google user: foogod

Hey all.. just started looking into synergy+ and came across this as I'd very much like this feature, however reading the discussion here I have to say all this discussion of rolling our own encryption protocols concerns me. In my opinion this is almost certainly the wrong way to do it.

Why are we not using SSL/TLS?

• It already does everything we need (bi-directional encryption, authentication, and data validation).
• Well-tested libraries are already available on all modern OSes, which means:
1. We don't have do to the coding ourselves.
2. It's much more likely to be free of security holes.
• The protocol and libraries are actively maintained by a large community, including many high-level security experts.
• It's actively used by a wide variety of other apps too, so any new security holes that people come up with will be noticed and corrected much more quickly.

(I know some people dislike TLS because they have the impression that it's cumbersome to use if you're not using certifying authorities, etc, but that's really not true if you design the app properly. ssh is a prime example of this.)

My suggestion:
* Server and client use TLS with self-signed key/certs.
* The first time, each server/client will generate its own keypair and store it locally.
* When connecting securely for the first time (or possibly when running some "ssl-setup" mode or etc), each end displays to the user the fingerprints of both itself and the other. The user is then asked to confirm that both sides are showing the same fingerprints and should be allowed to talk to each other.
* Upon confirmation, the certificate of the remote side is stored as an "authorized" certificate, and from then on connections using that cert do not need user confirmation.

(Note that this is basically the same model (and protocol) that ssh uses for host key validation.. I don't see why we shouldn't borrow from something that's been shown to work fairly well in wide use)

#78

29 Aug 2010 20:50: Jason Axelson wrote a comment.

Hi foogod,

Do you have any good links related to developing an application ussing SSL?

4 Sep 2010 10:24: Nick Bolton changed Target.

?

27 Dec 2010 16:24: Nick Bolton changed Status.

PatchesWelcome New

27 Dec 2010 16:24: Nick Bolton changed Status.

New Accepted

27 Dec 2010 16:24: Nick Bolton changed Target.

?

#79

3 Jan 2011 08:29: firexware firexware wrote a comment.

Hi, i REALLY like Synergy+ and would like to see encryption added as well. I have some crypto and coding background so I may be able to help.

First off, using SSL/TLS is much more than what is needed for something as simple as synergy. Also, a really old post says to use diffie-hellman. Do NOT use diffie-hellman, as you have to use insanely huge numbers for it to be secure, and it does not provide authentication.

My first thought would be to implement a simple pre-shared key approach as follows:

The user should be able to give the server, and each client a password (or randomly generated key). They would all store the password in a config file.
The client and server would authenticate like this:
1. Client generates 128 random bits, and sends it to the server (unencrypted)
2. Server generates a different random 128 bits, and sends it back to the client
- now, Client and server each have 256 bits of the same randomness, 128 of which was generated by themselves, so if there was a man in the middle modifying their communications, the following steps will fail;
3. Client concatenates (NOT XOR OR ADDITION, CONCATINATION) the two 128 parts together to form a 256 bit string.
4. Client computes sessionKey = H(password . random256Bits). The '.' means concatenation. H is a secure hash algorithm, like SHA256
5. Server does that same computation, and will obtain the same session key.

Now, this session key can be used to encrypt the communications, which I will discuss later. Doing it this way is secure because both the client and sever get to pick their own random numbers, not having to trust random bits sent over an insecure connection. If an attacker were to modify the client's bits as they were sent to the server, the server would compute the hash using the modified bits, the client would compute the hash using the original bits, and thus the session keys would end up being different. The same is true if the server's bits were modified.

Once they both have the session key, they can easily authenticate by:

1. Client generates 128 random bits, sends them to the server.
2. Server computes H(randomBits . sessionKey) and sends the answer back to the client
3. Client computes the same H(randomBits . sessionKey) and verfies that it is the same as what the server said
4. repeat the process to authenticate the client to the server

The only problem with this solution is that you have to store the password in plain text on each machine, or ask for the password every time. To me, this doesn't seem like such a bad idea, because if there were viruses on any of the machines, they could easily record every keystroke without bothering with synergy. It could be a problem in an office environment where machines are used by more than one person.

So after each client has their own session key, how should the encryption be done?

Assuming you're sending one packet per keystroke, I would use a good block cipher in CBC mode, with a random IV for every packet (look on wikipedia for CBC mode, they explain it better than I can). The reason why CBC (or other mode that uses IVs) is VERY important is because if the keystroke was just encrypted directly with the key, an attacker would be able to tell when the same key was pressed (same plaintext encrypts to the same ciphertext). Also, since you are using IVs it is VERY important to authenticate each ciphertext AND the IV, or else the attacker can change the IV to control how the data decrypts. I would use the following process:

1. Generate a random IV, using /dev/urandom (/dev/random strength isn't needed)
2. Encrypt the data in CBC mode, using that IV and whatever cipher you choose.
3. concatenate the IV and encrypted data (IV . encdata)
4. Compute hash = H(sessionKey . IV . encdata)
5. stuff it all in one packet so it ends up looking like hash . IV . encdata
When the packet is recieved:
6. pull the peices apart: hash, IV, encdata
7. compute H(sessionKey . IV . encdata), check that it is exactly the same as hash, if it is not STOP and IGNORE the packet
8. decrypt encdata using the IV and session key.

I would use AES-128 as the block cipher and SHA256 as the hash.

That's the best way to encrypt each packet, but there's a problem. That's 512 bits of overhead per packet depending on which hash algorithm and cipher you use. I've never done any serious network programming so I don't know how bad that would be. If you want to get rid of the overhead, you may need to complicate things. One way would be to have both sides keep track of a counter, and XOR that with the data before being encrypted, like CTR mode. Doing it that way would ensure that there is no overhead at all.

If you're ok with a little bit of overhead (just the IV so either 128 or 256 bits)
1. create a random IV
2. packetKey = H(IV . sessionKey)
3. use packetKey to encrypt the packet in ECB (normal) mode
4. send IV . encdata
when the packet is recieved:
5. separate IV and encdata
6. compute packetKey = H(IV . sessionKey)
7. decrypt the data, and see if it makes sense, if it doesn't, then ignore it (means a bad guy is messing with the data)
This is secure because if the attacker changes the IV, the packetKey will be different, and the data will decrypt to random noise.
For your case, it's ok to use ECB because:
1. the packets are small and don't have repetitive data
2. the key is different for every packet

That's how I would do encryption of individual packets. If you aren't sure about the pre-shared key approach, there is public key crypto, in which case I would opt to use a library, because it makes the whole process a bit more complicated, and I would have to do a bit more research to figure out the best way to share the session key. But I really don't think public key crypto is necessary because:
1. The computers are right beside each other, so typing a pre-shared key into each one isn't a big deal.
2. Storing the password on the machines isn't a big deal because any malware in the system can already detect every keystroke, and the only thing the password should be used for is synergy, and if someone found it, the user could easily change it (or maybe have a setting to ask for password each time)

The only scenarios where public key crypto are required are:
1. When the two machines are really far away (secure, physical key transfer is impossible)
2. one of the client machines is untrusted (either malware or other people using it)

All you need to implement this is:
1. AES code
2. SHA256 code
3. random number generator (use /dev/(u)random and CSPRNGwhateverTheWin32APIis)

If you need any more help, I can try. I'm terrible at C++, but I can help out with the crypto stuff.

#80

4 Jan 2011 00:55: firexware firexware wrote a comment.

I just wrote the key exchange and authentication process that i mentioned in the previous post, in C++.

You can find it here:

http://ossbox.com/index.php?page=simppsk

Hopefully the interface is easy enough to use. I'm 99.9999%% sure that this is a secure way to do it. However, this is the first thing I've written in C++ in a long time, so be on the lookout for any exploits like buffer overflows, pointer issues, etc.. I've tested it on Linux, it should compile on Windows. The only OS-specific part is the random number generator which uses CryptGenRandom on windows and reads from /dev/urandom on everything else. For the hash, I used SHA256 from OpenSSL, but it would be easy to add your own SHA256 code.

Feel free to modify the code to your needs and apply whatever license you want. If I have time, motivation, and can find some AES code, I will do an encryption class too.

To address the problem of one client having malware or an evil user steal the encryption key from the config file and using it to sniff the traffic from the other clients, all that needs to be done is for each client to have a different key, which wouldn't be hard to do. But I would be happy with just one key shared across all clients, because if you can't trust the machines your using, there really is no point to encrypting the traffic at all.

#81

9 Jan 2011 22:13: Timothee Besset wrote a comment.

I was looking through GnuTLS documentation and it looks quite straightforward to integrate. In particular GnuTLS offers Secure Remote Password (also known as TLS/SRP, see http://srp.stanford.edu/), and it's a quite portable and reputable library. I ran GnuTLS's TLS/SRP examples (see attached), it looks like it would only be a few hours to get this into synergy.

I don't want to be demeaning of the fine work done with cypher selections and implementing a custom protocol for this, but it really seems a better route for that kind of stuff to stick to proven and standardized solutions.

As it stands a basic TLS/SRP would be a few hours to integrate - most of the work probably being around working out the Windows and OSX builds - and once done leaves the door open to any number of more advanced systems later on if so desired.

9 Jan 2011 22:13: Timothee Besset uploaded a file.

gnutls-srp-examples.zip - Timothee Besset 9 Jan 2011 22:13

#82

10 Jan 2011 13:14: firexware firexware wrote a comment.

Yes TLS/SRP is perfect for synergy! I just didn't know it existed :P
Just have each client have their own password, and that's as secure as it gets.
Using TLS also gives you the advantage of not having to worry about adding new ciphers/hashes in the case of broken crypto, so this is a much better approach.
I approve :)

13 Jan 2011 11:11: Nick Bolton changed Found in ver.

2.0.0

13 Jan 2011 11:11: Nick Bolton changed Platform.

Various

#83

4 Jun 2011 22:36: Jean-Sébastien Dominique wrote a comment.

I like the idea but there is one problem: some countries have bans on whatever uses an encryption, and others limit how secure the encryption can be. Using TLS seems like a great idea. IANAL, but maybe we might need to make a version with encryption and a version without to be able to distribute it in those countries. It's not our problem if someone downloads it with encryption when it is illegal where they are, but it would be in the best interest of our users to provide them with a version they can use without fear of being fined or jailed, or worse, a country suing the project.

http://en.wikipedia.org/wiki/Restrictionsontheimportofcryptography
http://en.wikipedia.org/wiki/Cryptography#Legal
issues

Please not that these lists do not mention limitations on cryptography in each country, but that shouldn't be of our concern. As long as we provide a crypto-free version, we're good to go.

#84

15 Sep 2011 03:35: Nick Bolton wrote a comment.

Assigning to 1.4, we should use the "ugly patch" as it's named, since it's been the only real contribution so far (everything else is just hot air and blue sky thinking -- sorry).

As JS mentions, there are legal issues. So I believe the best solution (logistically speaking) is to ship this as a separate component (no big deal really), which means that users will need to deliberately download and install this (I will ensure that this is easy).

15 Sep 2011 03:35: Nick Bolton changed Status.

Accepted GotPatch

15 Sep 2011 03:35: Nick Bolton changed Assignee.

3

15 Sep 2011 03:35: Nick Bolton changed Target.

? 1.4.6

15 Sep 2011 03:35: Nick Bolton changed Found in ver.

2.0.0 1.3.x

29 Oct 2011 22:38: Nick Bolton changed Target.

1.4.6

3 Nov 2011 16:33: Nick Bolton changed Assignee.

3

#85

23 Dec 2011 17:46: James Babcock wrote a comment.

I installed Synergy and started playing around with it. It's pretty useful. Then I found this issue, uninstalled and ran away screaming.

The homebrew crypto scheme created by firexware probably does not work. I haven't looked at it too closely, but there is a general rule that you should never invent your own cryptosystem unless it's to publish in a journal and have peer reviewed. As for this particular one, I'm pretty sure it's vulnerable to a replay attack; if you observe a packet and know it corresponded to pressing 'q', you can't recognize other 'q' packets because they have different IVs, but you can send that same packet again and a 'q' will be typed. So if someone types a known string which contains all the letters you need, you can then inject keystrokes to root them ("Win+R cmd /c nastystuff").

Even worse, the fact that this was in the bug tracker for almost three years with a priority setting of "Low" shows such an absurd disregard for security that I couldn't possibly trust this project to not have other security problems.

#86

4 Mar 2012 15:22: Nick Bolton wrote a comment.

James Babcock, patches welcome.

4 Mar 2012 15:22: Nick Bolton changed Status.

GotPatch PatchesWelcome

#87

4 Mar 2012 15:47: Timothee Besset wrote a comment.

Wish I had time to work on this and pursue the TLS/SRP stuff .. it would be a pretty fun and instructive thing to do. But my original 'a few hours' estimate is probably off by a few truckloads :)

#88

6 Jun 2012 15:33: David Williams wrote a comment.

On the authentication side, take a look at how XIBO (http://xibo.org.uk) handles it. Each client generates a random ID string when it is installed that it uses when it communicates with the server. It is also configured with a "Server Key" string. Before the server will recognize it, you have to "register" the client with the server, then accept the client from the server's config. For the user/admin, the process is simple and straightforward, with no need for sneaker-net.

#89

5 Aug 2012 03:48: Abdul.Mohsen Al.Mansuor wrote a comment.

Is there a any progress on implementing SSL/TLS anytime soon? this application really great and works well, just missing the SSL encryption!

#90

24 Oct 2012 08:13: Joshua Rodman wrote a comment.

Some easy/lazy key exchange is good enough for me. I just dont like that its trivially ownable, I don`t have real secrets going on here.

#91

31 Oct 2012 14:44: Thomas Spear wrote a comment.

Hi all, I've been a user of Synergy for a while now and after seeing that funding was pulled, I thought I'd look at the issues I can vote on after donating. I saw this and it seemed promising, but I have some comments of my own.

Regarding the comment from Jul 10 2009 about using SSH. This would be ideal for me. Most of us that have a Windows box and need to do things in linux either dual boot or run PuTTY or both. My comment is that PuTTY already can setup an SSH tunnel, so why not just have a section in the config where you specify the path to PuTTY, and say either yes or no to using SSH. Then the PuTTY binary can be called with appropriate flags to build the tunnel before making the connection out. And if someone is wanting to control a Windows session from their Linux machine, then they very likely (probably 99%% of those interested in encryption) know that they would need to have something setup on the Windows machine to receive the SSH tunnel (IE PuTTY) and so would already have it setup before trying to make an encrypted connection.

I mean, personally, I'd love to see multiple options; SSH tunneling, SSL, PSK, etc... but seeing that this has been in progress two years is painful, when just calling the PuTTY binary with the right command line arguments could have been implemented in a couple of weeks.

Heck, I'll even give two scenarios.

1) PuTTY says their command line arguments for port forwarding are the same as OpenSSH's: http://the.earth.li/~sgtatham/putty/0.62/htmldoc/Chapter3.html#S3.8.3.5 -- we can call C:\path\to\putty.exe -L (someport):remotehost:(arbitraryport) 1.1) If we do the above, the user should already know that there needs to be something listening on the remote end to decrypt the data and forward it to the appropriate port for S+

2) You can save different sessions (profiles) in PuTTY. Say someone saves a profile as "Tunnel". All you need to do to get the tunnel setup on the Windows side is call PuTTY as follows: C:\path\to\putty.exe -load Tunnel 2.1) We can have the user either specify their already setup profile if they have one and load it up that way, or we can just use #1 above to create the tunnel from the command line.

Going one step beyond the above, could have the S+ client on the remote end call whatever is necessary to setup the receiving end of the tunnel (basically have the server and client attempt to negotiate a tunnel and tell each other the proper ports to use). That would allow for port randomization on both ends, and also removes the feeling of it being a stop-gap since the client and server are each calling commands locally on behalf of the user. The only drawback I can see of this is that the initial negotiation of the tunnel has to be unencrypted; however there is probably a way to work around that as well. I'm just not smart enough to think of anything other than kerberos that might be able to do that part of it.

SSH seems like the way to go since others have done all of the leg work already.

Anyways, this is just my two cents. I'm not a programmer though I do have a good bit of experience bug testing code, having been an off and on contributor to the wine project for a number of years.

#92

11 Nov 2012 16:34: Liam MacGillavry wrote a comment.

As Thomas Spear says, using Putty / Pageant as a base (on Windows) would be awesome. TortoiseSVN and (AFAIK) WinSCP do so, and it works like a charm.

18 Nov 2012 18:31: Nick Bolton changed Status.

PatchesWelcome Accepted

18 Nov 2012 18:31: Nick Bolton changed Target.

1.4.11

25 Nov 2012 22:33: Nick Bolton changed Details.

25 Nov 2012 23:54: Nick Bolton changed Status.

Accepted InProgress

25 Nov 2012 23:54: Nick Bolton changed Category.

System

25 Nov 2012 23:54: Nick Bolton changed Assignee.

Nick Bolton

#93

27 Nov 2012 13:43: Pete Swart wrote a comment.

I have been trying to run synergy over ssh for the last few weeks without success. This will be great when it is released.

In the meantime, if anybody can help me with my problem, it would be hugely appreciated, I have posted the details here: http://synergy-foss.org/osqa/questions/2213/synergy-over-ssh

29 Nov 2012 23:29: Nick Bolton changed Title.

Improve network security by using encryption Optional authenticated encryption

29 Nov 2012 23:29: Nick Bolton changed Details.

29 Nov 2012 23:29: Nick Bolton changed Title.

Optional authenticated encryption Authenticated encryption (optional)

#94

29 Nov 2012 23:54: Nick Bolton wrote a comment.

#95

20 Mar 2013 15:53: Joao Antunes wrote a comment.

Well, i'm using it over a VPN [OpenVPN], that is a good workaround (if you guys don't want to configure that, use SSH) untill this is implemented

8 Apr 2013 11:51: Nick Bolton changed Title.

Authenticated encryption (optional) Encryption

#96

8 Apr 2013 11:54: Nick Bolton wrote a comment.

The latest nightly build (r1716) features encryption. Its about a week away from being safe for production use, but currently works on all platforms (Windows, Mac and Linux) using a hard coded private key. When the finished, the user will easily set their own key based on a password via the GUI.

12 Apr 2013 03:54: Nick Bolton changed Status.

InProgress Fixed

#97

15 Apr 2013 15:29: Mark Bland wrote a comment.

Nick, thanks for all of your hard work on this! I hesitate to post this as it appears that you're still working on this feature but I thought just in case it would be helpful I should post it. (I'm also not sure if this is the correct place to post this)

I installed version 1.4.12-r1750 on Friday and experienced constant disconnects when having both my Windows box and Linux box as the host. The message in the log was :

ERROR: invalid message from client "Client-name":

I noticed that I could make it happen by typing quickly on one of the clients. I'm running Windows 8, Mac OS X 10.8, and RHEL 6. If there's any logs you want or troubleshooting you want me to try let me know.

Thank you again for this wonderful product and all of your hard work you've put into. I know I'm not the only person who greatly appreciates this product.

#98

16 Apr 2013 13:50: Nick Bolton wrote a comment.

To all: If you're experiencing problems with this feature, please look at bug #3565.

#99

6 May 2013 09:53: Stryker Blue wrote a comment.

I personally get the least latency by using an Ethernet cord between the server and client. One could probably use an ethernet router to hook up more computers. If you use local IPs within the routers allocation, then there is nothing to sniff since traffic is contained to that router. Encryption, however, would be nice to use, maybe OpenSSL or GNUTLS. I don't think Synergy itself should code the encryption but just use another source for it. Keep the applications separate and make it an optional dependency.

#100

6 May 2013 13:48: Nick Bolton wrote a comment.

Stryker, we actually use the Crypto++ library and do not "code the encryption" as you put it. If you are not happy using Crypto++, then please disable encryption and use SSH tunnelling instead. The trend seems to be that most users do not know how or do not want to use SSH tunnelling, and would prefer for this to be built into Synergy itself.

Discussing this further is a waste of time. Patches welcome.