Synergy

Google user: aidin.fanni

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

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.

Missing comment

Missing comment

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

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

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

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

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

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.

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.

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.

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.

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.

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

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

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

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

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

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.

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.

Google user: nick.bolton.uk

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

Missing comment

Missing 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

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

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.

Google user: VeNoMouS...@gmail.com

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

Google user: VeNoMouS...@gmail.com

Nick, How did you go? Any issues?

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

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.

Google user: palkina1

In short, !!RTFM!!

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

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

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.

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/

Anyway, work for tomorrow or the weekend.

ME BED, SLEEP 3:15am!!!

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

Google user: nick.bolton.uk

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

Missing comment

Google user: nick.bolton.uk

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

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

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.lib
http://files.edin.dk/php/win32/mcrypt/dev/include/mcrypt.h ===========================================================

Not the previous site I posted, Sorry...

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:

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

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?

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?

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

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.

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!

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

Google user: nick.bolton.uk

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.

Google user: docwhat

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

Google user: mattd00d82

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

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

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.

Google user: richardw...@gmail.com

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

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.

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.

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

Google user: VeNoMouS...@gmail.com

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

is it worth me picking this backup?

Google user: stevenhoneyman

yes, please do! :)

Google user: VeNoMouS...@gmail.com

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.

Google user: Andrew.Johnson.H

Let me know if you need help with anything.

Google user: VeNoMouS...@gmail.com

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

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.

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

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

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

Google user: nick.bolton.uk

Created a new trunk for experimental encryption code:

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

Anyone is welcome to commit changes. Hack away!

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

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

Hi foogod,

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

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:

6. Client generates 128 random bits, sends them to the server.
7. Server computes H(randomBits . sessionKey) and sends the answer back to the client
8. Client computes the same H(randomBits . sessionKey) and verfies that it is the same as what the server said
9. 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.

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.

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

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.

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.

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