Encryption about synergy-core

[nbolton]

• Author: aidin.fanni (Google user)
• Date: 2009-02-27 00:00:00

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

[nbolton]

• Author: sorin.sbarnea (Google user)
• Date: 2009-03-02 00:00:00

At least please vote for this
"http://code.google.com/p/support/issues/detail?id=314&q=tracker%%20edit&colspec=Stars%%20ID%%20Type%%20Status%%20Milestone%%20Priority%%20Stars%%20Owner%%20Summary":http://code.google.com/p/support/issues/detail?id=314&q=tracker%%20edit&colspec=Stars%%20ID%%20Type%%20Status%%20Milestone%%20Priority%%20Stars%%20Owner%%20Summary
This may speedup the adding of the edit feature to the bug summary.

[nbolton]

• Author: minupla (Google user)
• Date: 2009-03-05 00:00:00

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.

[nbolton]

• Date: 2009-05-23 00:00:00

-Missing comment-

[nbolton]

• Date: 2009-05-23 00:00:00

-Missing comment-

[nbolton]

• Date: 2009-05-23 00:00:00

-Missing comment-

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-04 00:00:00

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
of my head:

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-07-05 00:00:00

+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).

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-05 00:00:00

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.

[nbolton]

• Author: Jason.Donenfeld (Google user)
• Date: 2009-07-10 00:00:00

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.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-10 00:00:00

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

[nbolton]

• Author: minupla (Google user)
• Date: 2009-07-10 00:00:00

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.

[nbolton]

• Author: aidin.fanni (Google user)
• Date: 2009-07-13 00:00:00

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.

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-07-13 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-15 00:00:00

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-07-16 00:00:00

[email protected],

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-16 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-16 00:00:00

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/Block_cipher_modes_of_operation#Cipher_feedback_.28CFB.29":http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher_feedback_.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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-21 00:00:00

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.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-21 00:00:00

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.

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-07-22 00:00:00

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

[nbolton]

• Date: 2009-07-22 00:00:00

-Missing comment-

[nbolton]

• Date: 2009-07-22 00:00:00

-Missing comment-

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-27 00:00:00

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)

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-27 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-27 00:00:00

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-07-28 00:00:00

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.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-28 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-30 00:00:00

Nick, How did you go? Any issues?

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-07-30 00:00:00

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

[nbolton]

• Author: oct2274 (Google user)
• Date: 2009-08-06 00:00:00

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.

[nbolton]

• Author: palkina1 (Google user)
• Date: 2009-08-06 00:00:00

In short, !!RTFM!!

"http://www.inputdirector.com/faq.html#8_2":http://www.inputdirector.com/faq.html#8_2

A. 8.2 What ciphers does Input Director support?

Input Director currently offers the Advanced Encryption System (AES) cipher. If you
are after a different cipher, please contact the author as this can be probably be
accommodated.

Return to top
A. 8.3 Which encryption library does Input Director use?

Input Director uses the OpenSSL library version 0.9.8g

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-10 00:00:00

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.

[nbolton]

• Date: 2009-08-13 00:00:00

-Missing comment-

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-13 00:00:00

[email protected],

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.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-08-13 00:00:00

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.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-08-13 00:00:00

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

nick, you got msn messenger or something to talk about this offlist?

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-13 00:00:00

Sure, either IRC (#synergy-plus on Freenode) or Google talk (use my Google username).

[nbolton]

• Date: 2009-08-13 00:00:00

-Missing comment-

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-14 00:00:00

Oh, and I forgot to mention. You may find our code style guide helpful.
"http://code.google.com/p/synergy-plus/wiki/Specification#4.2._Code_style":http://code.google.com/p/synergy-plus/wiki/Specification#4.2._Code_style

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-08-14 00:00:00

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-14 00:00:00

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:

ld: library not found for -lmcrypt

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-16 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-08-16 00:00:00

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?

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-08-16 00:00:00

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! :)

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-09-01 00:00:00

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.

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-09-01 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-10-27 00:00:00

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-10-28 00:00:00

Haha, nice ;) someone was actually asking about this in the IRC channel, so it seems
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.

[nbolton]

• Author: docwhat (Google user)
• Date: 2009-10-29 00:00:00

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!

[nbolton]

• Author: mattd00d82 (Google user)
• Date: 2009-11-13 00:00:00

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-11-13 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-11-13 00:00:00

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.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2010-03-10 00:00:00

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

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2010-03-12 00:00:00

richardwiden, patches welcome!

[nbolton]

• Author: Andrew.Johnson.H (Google user)
• Date: 2010-04-08 00:00:00

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

[nbolton]

• Author: BostonVaulter (Google user)
• Date: 2010-05-02 00:00:00

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.

"http://code.google.com/p/synergy-plus/wiki/Branches":http://code.google.com/p/synergy-plus/wiki/Branches

[nbolton]

• Author: [email protected] (Google user)
• Date: 2010-05-03 00:00:00

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

is it worth me picking this backup?

[nbolton]

• Author: stevenhoneyman (Google user)
• Date: 2010-05-03 00:00:00

yes, please do! :)

[nbolton]

• Author: [email protected] (Google user)
• Date: 2010-05-03 00:00:00

Alright I haven't really been much lately except google map harvesting (long story)
and captcha work arounds...

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

[nbolton]

• Author: Andrew.Johnson.H (Google user)
• Date: 2010-05-03 00:00:00

Let me know if you need help with anything.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2010-05-09 00:00:00

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

[nbolton]

• Author: [email protected] (Google user)
• Date: 2010-05-09 00:00:00

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.

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2010-06-05 00:00:00

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
list if I'm not on IRC: "http://groups.google.com/group/synergy-plus-dev":http://groups.google.com/group/synergy-plus-dev

[nbolton]

• Author: [email protected] (Google user)
• Date: 2010-06-06 00:00:00

@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
something bad.

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.

Just things to think about.

[nbolton]

• Author: BostonVaulter (Google user)
• Date: 2010-06-06 00:00:00

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?

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2010-06-07 00:00:00

Created a new trunk for experimental encryption code:

svn co "https://synergy-plus.googlecode.com/svn/branches/crypto":https://synergy-plus.googlecode.com/svn/branches/crypto synergy-plus-crypto

Anyone is welcome to commit changes. Hack away!

[nbolton]

• Author: foogod (Google user)
• Date: 2010-06-07 00:00:00

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)

[nbolton]

• Author: Jason Axelson
• Date: 2010-08-29 20:50:49

Hi foogod,

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

[nbolton]

• Author: firexware firexware
• Date: 2011-01-03 08:29:44

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;
• Client concatenates (NOT XOR OR ADDITION, CONCATINATION) the two 128 parts together to form a 256 bit string.
• Client computes sessionKey = H(password . random256Bits). The '.' means concatenation. H is a secure hash algorithm, like SHA256
• 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:
8. the packets are small and don't have repetitive data
9. 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.

[nbolton]

• Author: firexware firexware
• Date: 2011-01-04 00:55:39

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.

[nbolton]

• Author: Timothee Besset
• Date: 2011-01-09 22:13:55

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.

[nbolton]

• Author: firexware firexware
• Date: 2011-01-10 13:14:49

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

[nbolton]

• Author: Jean-Sbastien Dominique
• Date: 2011-06-04 22:36:39

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/Restrictions_on_the_import_of_cryptography
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.

[nbolton]

• Author: Nick Bolton
• Date: 2011-09-15 03:35:14

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

[nbolton]

• Author: James Babcock
• Date: 2011-12-23 17:46:37

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.

[nbolton]

• Author: Nick Bolton
• Date: 2012-03-04 15:22:36

James Babcock, patches welcome.

[nbolton]

• Author: Timothee Besset
• Date: 2012-03-04 15:47:31

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

[nbolton]

• Author: David Williams
• Date: 2012-06-06 15:33:27

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.

[nbolton]

• Author: Abdul.Mohsen Al.Mansuor
• Date: 2012-08-05 03:48:25

sorry for my bad English

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

[nbolton]

• Author: Joshua Rodman
• Date: 2012-10-24 08:13:28

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.

[nbolton]

• Author: Thomas Spear
• Date: 2012-10-31 14:44:43

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.

[nbolton]

• Author: Liam MacGillavry
• Date: 2012-11-11 16:34:08

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.

[nbolton]

• Author: Pete Swart
• Date: 2012-11-27 13:43:23

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

[nbolton]

• Author: Nick Bolton
• Date: 2012-11-29 23:54:05

Please discuss here: https://groups.google.com/forum/?fromgroups=#!topic/synergy-plus-dev/hwgTJpjNQyY

[nbolton]

• Author: Joao Antunes
• Date: 2013-03-20 15:53:55

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

[nbolton]

• Author: Nick Bolton
• Date: 2013-04-08 11:54:31

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.

[nbolton]

• Author: Mark Bland
• Date: 2013-04-15 15:29:12

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.

[nbolton]

• Author: Nick Bolton
• Date: 2013-04-16 13:50:16

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

[nbolton]

• Author: Stryker Blue
• Date: 2013-05-06 09:53:06

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.

[nbolton]

• Author: Nick Bolton
• Date: 2013-05-06 13:48:03

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.

[nbolton]

• Author: Thomas Spear
• Date: 2013-08-12 15:58:03

I recently had a bout of trying to setup encryption through SSH tunneling because RHEL5 only had a package using the old version prior to encryption being addesd, and so I had downgraded my Windows machine to the old version (I later decided that was a bad idea and so I built Synergy from source for the RHEL5 machine. What a process! Thank YOU Nick for the great documentation!

Anyways, I thought I would provide a simple walkthrough for what I did for those that don't know how to enable SSH Tunneling between Windows (host/server) and Linux (client), in case anyone is interested. If there is a better place (such as the wiki), please feel free to copy this there (or ask me to do so and I will).

First, some notes:

1. This works with ANY version of Synergy, whether encryption is built in or not. If you're really paranoid, you could probably even use SSH Tunneling with Synergy's built-in encryption enabled if you wanted to prevent even someone with root access to your machine from doing an advanced packet dump and reading what's sent across the SSH connection (technically it is possible, but very difficult.)
   
2. As I noted, this is from a Windows host (server) to a Linux client. This is different from the walkthrough currently on the wiki in that you're establishing the SSH tunnel before Synergy is started on the client machine. This is handy in some niche cases where you have a monitor with dual inputs, similar to a television, but no dedicated monitor for the linux machine, resulting in use of SSH for most things on said machine. Since you're already using an SSH connection, why not also recycle that connection as your tunnel? Another nicety of this is that it requires only one change to the synergy configuration on the client side and none on the server side.
   
3. This requires installation of PuTTY on the Windows machine. You can get PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html so if you're using another SSH client, I cannot provide you instructions for that; hopefully you can adapt these instructions to work for your SSH client.
   
4. Unfortunately, while this has a few advantages, it comes with one disadvantage. The Linux machine will not connect to the server until the SSH Tunnel is brought up from the Windows machine. This should be obvious but I wanted to state that anyways. So if you have a synergy startup script, be mindful that you won't have a truly interactive logon (and won't be able to intervene in the init process, or login to X or shell) until the tunnel is up.
   
   

Now that the notes are out of the way, on to the actual instructions!

1. Once you have downloaded and launched PuTTY, have a look on the left hand side. There will be a number of different categories you can click on to make settings changes. You'll want to click the plus sign next to SSH, near the bottom, then click on Tunnels.
   
2. Ensure that all "Port Forwarding" check boxes are not checked. This opens up the ports you have forwarded so that other machines can access them, which is not something you want if you're concerned with security.
   
3. What we are going to do is setup a Remote port to listen for a connection and forward that connection back to the Windows machine (reverse port forwarding). So in order to setup the tunnel properly, look in the bottom half of this window. There you will see "Add a new forwarded port:" -- this is where you will setup your port forwards.
   
4. In the Source port field, enter "24800" (or whatever port your Synergy client connects to). In the Destination field, enter "localhost:24800" or whatever port your Synergy server listens on. This should be the same number as the Source port. Make certain that you DO enter "localhost:" before the port number for the Destination, but not for the Source! Then click Remote (you MUST do this or the tunnel will not facilitate the connection from the client to the server.) Finally, click Add.
   
5. Now in the Forwarded ports field, you should see "R24800 localhost:24800" -- If you see that, look on the left again, and click on the Session category at the top, and save your session (give it a name if you've never saved a session before!)
   
6. On your linux machine, edit your synergy startup script, or make sure to modify the command line as follows. When you are connecting, rather than using the server's hostname or IP address, you will now want to connect to localhost, and make sure that you don't use the -1 flag (which causes synergyc to exit if it cannot establish a connection.) The reason for connecting to localhost is because the port forward from the Linux machine back to the Windows machine is being setup by PuTTY when the SSH session is negotiated, not being setup from the Linux side.
   
   

That's it! You're done! Start your synergy server on Windows, then start the synergy client on Linux. As long as you used localhost for the Linux client's hostname, and you're able to move the mouse around on the Linux client machine, then you've gotten it working! If it does not work, you can use PuTTY's RAW connection type to connect to port 24800 on either machine and verify whether the tunnel is working or not (open a second instance of PuTTY, but do not close the first SSH session, since it holds the tunnel.) If you have to do that, then you will see the word "Synergy" appear in the PuTTY screen when trying to connect if it is working, and you will get "connection refused" or some other such error (or a blank screen.)