I'm trying to establish a secure connection in C#, and I'm not sure I'm doing it right. :(

Here is my encryption class:

/*The contents of this file are subject to the Mozilla Public License Version 1.1
(the "License"); you may not use this file except in compliance with the
License. You may obtain a copy of the License at http://www.mozilla.org/MPL/

Software distributed under the License is distributed on an "AS IS" basis,
WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for
the specific language governing rights and limitations under the License.

The Original Code is the GonzoNet.

The Initial Developer of the Original Code is
Mats 'Afr0' Vederhus. All Rights Reserved.

Contributor(s): ______________________________________.
*/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Security.Cryptography;

namespace GonzoNet.Encryption
{
    public class ARC4Encryptor : Encryptor
    {
        private DESCryptoServiceProvider m_CryptoService = new DESCryptoServiceProvider();
        private ICryptoTransform m_DecryptTransformer, m_EncryptTransformer;
        public byte[] EncryptionKey;

        public ARC4Encryptor(string Password)
            : base(Password)
        {
            PasswordDeriveBytes Pwd = new PasswordDeriveBytes(Encoding.ASCII.GetBytes(Password), 
                Encoding.ASCII.GetBytes("SALT"), "SHA1", 10);
            EncryptionKey = Pwd.GetBytes(8);
            m_DecryptTransformer = m_CryptoService.CreateDecryptor(EncryptionKey, Encoding.ASCII.GetBytes("@1B2c3D4e5F6g7H8"));
            m_EncryptTransformer = m_CryptoService.CreateEncryptor(EncryptionKey, Encoding.ASCII.GetBytes("@1B2c3D4e5F6g7H8"));
        }

        public ARC4Encryptor(string Password, byte[] EncKey)
            : base(Password)
        {
            PasswordDeriveBytes Pwd = new PasswordDeriveBytes(Encoding.ASCII.GetBytes(Password),
                Encoding.ASCII.GetBytes("SALT"), "SHA1", 10);
            EncryptionKey = EncKey;
            m_DecryptTransformer = m_CryptoService.CreateDecryptor(EncryptionKey, Encoding.ASCII.GetBytes("@1B2c3D4e5F6g7H8"));
            m_EncryptTransformer = m_CryptoService.CreateEncryptor(EncryptionKey, Encoding.ASCII.GetBytes("@1B2c3D4e5F6g7H8"));
        }

        public override DecryptionArgsContainer GetDecryptionArgsContainer()
        {
            DecryptionArgsContainer DArgsContainer = new DecryptionArgsContainer();
            DArgsContainer.ARC4DecryptArgs = new ARC4DecryptionArgs();
            DArgsContainer.ARC4DecryptArgs.Transformer = m_DecryptTransformer;

            return DArgsContainer;
        }

        public override byte[] FinalizePacket(byte PacketID, byte[] PacketData)
        {
            MemoryStream FinalizedPacket = new MemoryStream();
            BinaryWriter PacketWriter = new BinaryWriter(FinalizedPacket);

            MemoryStream TempStream = new MemoryStream();
            CryptoStream EncryptedStream = new CryptoStream(TempStream,
                m_EncryptTransformer, CryptoStreamMode.Write);
            EncryptedStream.Write(PacketData, 0, PacketData.Length);
            EncryptedStream.FlushFinalBlock();

            PacketWriter.Write(PacketID);
            //The length of the encrypted data can be longer or smaller than the original length,
            //so write the length of the encrypted data.
            PacketWriter.Write((ushort)((long)PacketHeaders.ENCRYPTED + TempStream.Length));
            //Also write the length of the unencrypted data.
            PacketWriter.Write((ushort)PacketData.Length);
            PacketWriter.Flush();

            PacketWriter.Write(TempStream.ToArray());
            PacketWriter.Flush();

            byte[] ReturnPacket = FinalizedPacket.ToArray();

            PacketWriter.Close();

            return ReturnPacket;
        }

        public override MemoryStream DecryptPacket(PacketStream EncryptedPacket, DecryptionArgsContainer DecryptionArgs)
        {
            CryptoStream CStream = new CryptoStream(EncryptedPacket, m_DecryptTransformer, CryptoStreamMode.Read);

            byte[] DecryptedBuffer = new byte[DecryptionArgs.UnencryptedLength];
            CStream.Read(DecryptedBuffer, 0, DecryptedBuffer.Length);

            return new MemoryStream(DecryptedBuffer);
        }
    }
}

Then I initialize it as such on the client and server side:

            //Doing the encryption this way eliminates the need to send key across the wire! :D
            SaltedHash Hash = new SaltedHash(new SHA512Managed(), Args.Username.Length);
            byte[] HashBuf = Hash.ComputePasswordHash(Args.Username, Args.Password);
            Args.Enc = new GonzoNet.Encryption.ARC4Encryptor(Convert.ToBase64String(HashBuf));

Then when establishing the secure connection, I'm sending the hash across. What I'm wondering is: Could the hash be used to generate the key by a man-in-the-middle attacker?

If so, would it help to Blowfish the hash using itself as they key, so that if the hash stored in the DB is correct, it will be able to decrypt itself?

Should I just rewrite the protocol using Diffie-Helllman?

Thanks guys! :)

I've had a think, and I've decided that using TLS isn't neccessary. This is an open source project, so people can figure out the protocol either way. And there's no way they can retrieve the password from the hash.

However I won't remove the encryption currently in place, because its been a learning experience. I'll switch to using RSA key exchange just because I can. :)

Huh?

The first thing hplus asked me was "is this really an attack you need to worry about?"

I thought about it, and I decided "no".

Also, are you suggesting that hashing a password with SHA512 isn't safe (enough?) to send in plaintext, and it needs to be encrypted in addition?

Lastly, if I'm going to use encryption at all, what's wrong with using RSA key exchange?

The main reason I really don't want to use TLS is because it just seems overly complex. I did some research, and I haven't been able to figure out how to generate a "self signed root certificate". Can I do this programmatically?

Then would it not be safer to encrypt everything in the first packet BUT the accountname with AES, so that if the accountname's corresponding hash in the DB can descramble the packet, that hash can be used to encrypt communication onwards? Why/why not?

Also, are you suggesting that hashing a password with SHA512 isn't safe (enough?) to send in plaintext, and it needs to be encrypted in addition?

Lastly, if I'm going to use encryption at all, what's wrong with using RSA key exchange?

The main reason I really don't want to use TLS is because it just seems overly complex.

You already need half a PhD to figure out how to use it at all, which is a shame because the universally given answer "do not run your own crypto stuff, you will do it wrong" is almost certainly true. Without even looking at your code and without even knowing your skill level, one can tell with very high confidence that you did it wrong.

That said, because I find TLS and OpenSSL obnoxious for their complexity, I would recommend to use NaCL if you can get it to compile (compiling is admittedly a challenge!), or recommend that you do an ECDH key exchange both for authentication.and establishing a session key, with the curve25519 library (same author). That one is one source file, and a single function call and so easy that even a brain-damaged monkey couldn't do wrong, and both speed and key sizes are "very manageable". As in, 32 bytes per key, and upwards of 20,000 ops per second.

For example, a scheme like this one is pretty acceptable (not 100% secure, but as good as it gets without getting overly complicated, and by all means good enough for a game):

• Store the server's public key (32 bytes) in the client executable
• When the user creates an account (via a web interface or whatever means), hash username+password a few dozen times. This is the user's private key. Generate a public key from that (one function call) and immediately throw the private key away after that. Store the public key in the database on the server.
• Whenever the user wants to log in, send the username. The server sends back a message encrypted using a key derived from its private key and the user's public key. Meanwhile the client program hashes the entered password to figure out the user's private key.
• The client decrypts the message using the user's private key and the server's public key stored in the executable. The decrypted message contains a random session key and a challenge response valid for that connection.
• The client uses the session key to encrypt all further traffic and sends the challenge response. The server won't talk to anyone who doesn't send the correct challenge response, and someone who doesn't know the user's private key (i.e. the password) won't know the session key and won't be able to understand any of the communication or send meaningful commands.

This system is of course not 100% secure, but it is simple and immune to all common and reasonably realistic technical attacks (there are a few additional minor details about what "encrypt" means and such, but in principle it's not much more complicated than that). Social attacks of course still work, but they work on every system, regardless of how clever you think they are... you simply can't prevent a user from giving away his password or from installing that porn-trojan or that keylogger on his computer.

Someone might root the server and steal users' passwords while they create accounts, but that's something you can always do when you are in total control the server. It's no problem insofar as you already control the complete server, so stealing a user's game password is no concern.

Further, a disgruntled employee might run off with the server's private key, or a hacker might steal it, much like a hacker might steal the user password database. While the server's private key will allow for impersonating/cloning the server or for a MITM attack, it is only useful provided that you can also successfully subvert the DNS system or that you work at an ISP or such, so you can conceivably run a MITM (for most people who are not ISP employees or secret service agents, this is a rather theoretical attack without much of a practical value). Otherwise, the server's private key is completely worthless, it won't let you log into the game. Nor will the stolen user database, since they're public keys only.

For a game, I daresay this is absolutely sufficient, but if you're worried, you can still make it more complicated (letting keys expire, sign them, whatever). Personally, I think that's using a sledgehammer to crack a nut (...for a game).

Though of course, on a second thought... the most common DSL router in the EU (which powers e.g. about 50% of the internet access in Germany) can be trivially exploited and still 3/4 of users haven't upgraded their firmware two months later if you can believe what's said on the news. From that point of view, it might be conceivable for a runaway employee who isn't the leader of a top international crime organization and who isn't a CIA employee to run a MITM on users via their router. However, those users would likely be the same users who will tell you their password, too.