RS Chat

Project history

Since I started programming, a chat application was kind of a milestone. A very primitive chat application can be developed by making a TCP connection and sending a message through it when you press the send button on the form. Not hard at all, but since it involves networking, it's considered stepping to the next level, if you're a complete beginner.

I started tasting C# in the beginning of 2007. Writing a chat application was one of my goals, but due to the lack of knowledge at that time, that wasn't doable. In January 26th, 2008, I finally went for it for the first time.

RS Chat v1 January 26th, 2008

The application made two TCP connections, a server and a client on both ends. I don't know why I did this, since TCP sockets are bidirectional. Probably I didn't know this then.

I really wanted to make it secure, so I made some encryption functions. It used AES and TripleDES, but because I was lacking real cryptographic knowledge, they were improperly padded and used ECB. The password was generated dynamically, where I relied on security through obscurity. Yeah, I know now, that's not a good idea, especially when the generated assembly can be really easily decompiled and analysed.

Overall, the application is functional, but has lots of issues.

Screenshot

RS Chat v2 October 19th, 2009

After gaining some usable knowledge, I restarted the project from scratch. And this time, it only used one TCP socket to communicate. :)

This time I made an actual protocol and documented it. It didn't blindly send strings anymore. It had 7 commands: CONNREQ, CONNOK, PING, PONG, TYPING, NOTTYPING, MESSAGE. Every command ended with a null, so they could be separated on the stream.

For encryption it used Blowfish and AES with a key derived using PBKDF2 which was salted using a shared secret key using Diffie-Hellman key exchange on the CONNREQ command. Optionally it could pass the whole stream through [SslStream](http://msdn.microsoft.com/en-us/library/system.net.security.sslstream.aspx) providing an extra layer of security.

This version had some more advanced features: it could measure connection latency and show when the remote user is typing.

I attempted developing a file transfer feature, but since I was trying to push the file through the active connection, it was extremely slow and blocked the whole connection while the transfer was running.

Screenshots

RS Chat v3 October 20th, 2010

Exactly a year and a day later, I restarted the development, again, from scratch. This time I'm focusing on performance, extensibility and to do cryptography right.

Now I fully understand the concept of object-oriented programming and I know a thing or two about cryptography.

Main components

When a message is sent or an event is fired, these are the interfaces it needs to goes through – but not in the listed order. Every single part in the application is extensible:

• Connection This interface makes the connection between the two clients and is responsible for delivering and receiving byte[] packets. Everything can be used what implements the members of the IConnection interface.
  • TCP sockets The messages sent on TCP sockets are padded with a 7-bit encoded unsigned 32-bit integer. There's support for SOCKS5 proxies, so you can use an SSH tunnel or an anonymizing service, such as TOR or I2P.
  • UDP sockets Full support for connection-less datagrams. Because the application sends pings it'll know when the connection is not alive anymore.
  • SCTP sockets An exotic transport layer which has the best features of both TCP and UDP. There is no native support in Windows for this protocol, but a port of the BSD SCTP stack to Windows exists: SctpDrv.
• Encryption This interface is responsible for encrypting the byte[] packets before they are sent. Anything implementing the IEncryption interface.
  • .Net Wrapper This wrapper provides support for classes which extend the SymmetricAlgorithm class. This means every encryption algorithm in the System.Security.Cryptography and Mono.Security.Cryptography namespace, plus dozens downloadable from the internet.
  • BouncyCastle Wrapper This wrapper provides support for every block cipher and stream cipher in the BouncyCastle Extended library.
  • Multi-Layer Encryption This isn't an actual encryption provider, since it allows you to create a chain of encryption algorithms therefore allows you to use multiple layers of encryption. No limit is set on the layer count, however there's really no reason to use 5 or more at once... Dedicated to the über-paranoid. :)
• Key exchange This is responsible for exchanging keys securely on a connection, therefore even if the passwords were compromised, the connection is still secure due to the randomly generated shared secret key. Anything implementing the IKeyExchange interface can be used.
  • Diffie-Hellman key exchange Generates 1536-bit keys using the 1536-bit prime number described in RFC 3526.
  • Elliptic-Curve Diffie-Hellman key exchange Generates 256-bit keys using the Cryptography API: Next Generation shipped with Windows 7.
• Compression This is responsible for compressing larger chunks of data. Anything implementing the ICompression interface can be used. Unfortunately this isn't very useful, since the average size of a packet is about 20 bytes, which can't be compressed.
  • Deflate
  • GZip
• Packet serialization This interface is responsible for serializing classes into byte[] and then deserializing them back to their original type on the other end. Anything implementing the ISerializer interface can be used.
  • Packet Serializer This is a special class for serializing the Packet and its derived classes into the smallest possible binary form.
  • Binary Serializer Packet serialization the BinaryFormatter way.
  • XML
  • BSON
  • JSON
• Text formatters These are used to format your messages.
  • Markdown
  • Textile

File transfers

For the first time ever, I've succeded at implementing high-speed secure file transfers. When a file transfer is initiated, the software creates an unidirectional TCP socket on the server side and starts sending the file. The reason why not necessarily the file sender is used as a server is really simple: it might not be reachable, it might be behind a firewall or NAT. If the client originally used a proxy to create a connection, then that proxy will be contacted again to initiate the file transfer through it.

The file transfer being on another form, thread and connection, has the ability to continue the transfer even if the main chat connection is closed or lost. The connection used for the transfer, as stated above, is unidirectional and will close automatically after the size of the file is received, therefore it's not a security concern.

The speed of the transfers average on 95 MB/s. If encryption is enabled, the speed is really determined by the algorithm in use, but if a high-speed stream cipher is chosen, then the speed is around 60 MB/s.

Identity verification

If you're very paranoid you might be concerned about your connection being rerouted to someone else, or the DNS resolving to the fake IP, or to man-in-the-middle attacks. Version 1 and 2 didn't address this issue. Version 3 however, supports using SSL certificates to authenticate the connection and to tamper-proof every single packet. Any certificate that can be used for email encryption, can be used for this purpose too. You can get fully free email certificates from CACert, StartCom or InstantSSL.

Some ideas

These didn't make it into the software yet, but they're on my TODO list:

• Avatars – Small JPEG pictures could be sent in the handshake
• Smiles and other text formatting features
• Manual confirmation for SSL certificates
• Easier connect window – possibly with a nice wizard-ish design, because the current is far too advanced for a regular user

Screenshots

Encrypted file transfers

This transfer has been proxied through a public anonymous proxy so I could capture the file transfer. It's safe to do this, because the connection is encrypted and every packet is signed to prevent tampering.

New connection window

The settings aren't sent in the handshake packet, which means if your settings don't match, the connection will fail instantly.

 

RS Chat v4 August 18th, 2012

The development has been restarted, however this time it's only developed as a low-priority hobby project, and I mainly focus on writing clean code behind a thought-out and extensible architecture.

The project is currently under development. As of now, there isn't even an UI or a protocol, just a bunch of classes.

Things implemented so far

• Connection This interface is responsible for delivering byte[] packets between two clients.
  • TCP sockets
    • Data separation The problem with TCP is that packets are buffered when sent, and reconstructed into a stream at the other side. The separation of messages needs to be done in client code. The following methods are implemented:
      • Length-padding of messages using an 8 to 64-bit unsigned integer
      • Buffering incoming messages and separating them when a byte[] sequence is encountered
      • No message separation; fires an event if 1 or more bytes were read into the 8192-byte buffer
    • Connection helpers These classes can override the behaviour of TCPSocket.Connect()
      • SOCKS5 Initiates the TCP connection through a SOCKS5 proxy.
      • HTTPS Initiates the TCP connection through a HTTP proxy that supports the CONNECT method to ports other than 443.
  • UDP sockets
    • Data separation The problem with UDP is that packets are not guaranteed to be delivered, and they can be up to only 65536 bytes in size. For messages more than 65 kB, the packet will be fragmented. The following methods are implemented for packet reconstruction:
      • Length-padding of messages using an 8 to 64-bit unsigned integer
      • Buffering incoming messages and separating them when a byte[] sequence is encountered
      • No message separation; fires an event for each incoming UDP packet
• Protocols This interface is responsible for actually communicating once a connection is opened.
  • Plain-text protocol This protocol was supposed to be similar syntactically to the IRC protocol. It isn't the default protocol, since it is only implemented for fun, debugging and educational purposes. It's a priority to make the protocol as simple as possible so you are able to telnet into the software and chat, but add complex features to it as well, so when humans are not involved, the software will be able to initiate videochat sessions.
  • Binary protocol This is the smallest, fastest and default protocol. The smallest payload is 2 bytes, which is the unsigned 16-bit identifier of an Event object which will be initialized and fired at the other end. Additional bytes will be deserialized into an object array and passed to the Event.
• Encryption This interface is responsible for encrypting the byte[] packets before they are sent.
  • .Net Framework This provider adds support for classes which extend the SymmetricAlgorithm class. This means every encryption algorithm in the System.Security.Cryptography and Mono.Security.Cryptography namespace, plus dozens downloadable from the internet.
  • BouncyCastle This provider adds support for every block cipher and stream cipher in the BouncyCastle Extended library.
  • Crypto++ This provider adds support for the block and stream ciphers implemented in the Crypto++ library. A native CryptoPPHelper VC++ project (CryptoPP.dll and CryptoPP64.dll) exposes the classes from within Crypto++ and the RoliSoft.Chat.Encryption.Providers.CryptoPP C# project provides the P/Invoke interfaces to communicate with it.
  • Botan This provider adds support for the block and stream ciphers implemented in the Botan library. A native BotanPPHelper VC++ project (Botan.dll and Botan64.dll) exposes the classes from within Botan and the RoliSoft.Chat.Encryption.Providers.Botan C# project provides the P/Invoke interfaces to communicate with it.
  • MCrypt This provider adds support for the block and stream ciphers implemented in the library version of MCrypt. The RoliSoft.Chat.Encryption.Providers.MCrypt C# project communicates via P/Invoke with the untouched libmcrypt.dll file compiled in VC++. The x64 compilation of libmcrypt was problematic, therefore it is not available. If an x64 process must use the libmcrypt library, it can do it by spawning a separate x86 process (the RoliSoft.Chat.Helpers.MCryptIPCHost project) with which it will communicate using IPC named pipes.
  • OpenSSL This provider adds support for the block and stream ciphers implemented in OpenSSL. The RoliSoft.Chat.Encryption.Providers.OpenSSL C# project communicates via P/Invoke with the untouched libeay32.dll and ssleay32.dll files compiled in VC++ for both x86 and x64 separately.
• Compression This interface is responsible for compressing the byte[] packets before they are sent.
  • .Net Framework This provider adds support for the Deflate and GZip algorithms implemented in the .Net Framework.
  • SharpCompress This provider adds support for the algorithms implemented in the SharpCompress library. These are managed implementations, and the really good algorithms (such as PPMd for text compression) tend to be a bit slow and introduce a visible lag.
  • SevenZipSharp This provider adds support for the algorithms implemented in the native 7zip library through the managed SevenZipSharp library. These algorithms are unmanaged and run pretty fast, however they're not compatible with Mono.
• Hashing This interface is responsible for hashing the byte[] packets before they are sent.
  • .Net Framework This provider adds support for classes which extend the HashAlgorithm class. This means every hashing algorithm in the System.Security.Cryptography and Mono.Security.Cryptography namespace, plus dozens downloadable from the internet.
  • BouncyCastle This provider adds support for every hash algorithm in the BouncyCastle Extended library.
  • HashLib This provider adds support for the hash algorithms implemented in the HashLib library.
  • Crypto++ This provider adds support for the hash algorithms implemented in the Crypto++ library. A native CryptoPPHelper VC++ project (CryptoPP.dll and CryptoPP64.dll) exposes the classes from within Crypto++ and the RoliSoft.Chat.Hashing.Providers.CryptoPP C# project provides the P/Invoke interfaces to communicate with it.
  • Botan This provider adds support for the hash algorithms implemented in the Botan library. A native BotanPPHelper VC++ project (Botan.dll and Botan64.dll) exposes the classes from within Botan and the RoliSoft.Chat.Hashing.Providers.Botan C# project provides the P/Invoke interfaces to communicate with it.
  • MHash This provider adds support for the hash algorithms implemented in the library version of MHash. The RoliSoft.Chat.Hashing.Providers.MHash C# project communicates via P/Invoke with the untouched libmhash.dll file compiled in VC++. The x64 compilation of libmhash was problematic, therefore it is not available. If an x64 process must use the libmhash library, it can do it by spawning a separate x86 process (the RoliSoft.Chat.Helpers.MCryptIPCHost project) with which it will communicate using IPC named pipes.
  • OpenSSL This provider adds support for the hash algorithms implemented in OpenSSL. The RoliSoft.Chat.Hashing.Providers.OpenSSL C# project communicates via P/Invoke with the untouched libeay32.dll and ssleay32.dll files compiled in VC++ for both x86 and x64 separately.

Things to be implemented

• Anonymous communication through deepwebs The considered protocols are:
  • Tor Both sides would run a Tor client with a hidden service. Packets will be onion-routed between two .onion destinations, therefore they'd go completely through Tor and never reach clearnet.
  • I2P Both sides would run an I2P client with a local destination tunnel, or whatever the hell they call it. Packets will be garlic-routed between two .b32.i2p destinations, therefore they'd go completely through I2P and never reach clearnet.
  • Hyperboria To reach this network, nothing else may be required other than IPv6 support. Which is already supported. More info coming soon.
• Identity store in public DHTs An identity, public key, or most likely hash of public key may be stored in a decentralized database, for IP address retrieval by other parties that want to contact the said identity. Since the software doesn't have millions of active users, I was thinking of abusing currently active DHTs:
  • Mainline DHT You are probably connected to it right now: are you running µTorrent or an other DHT-capable BitTorrent client? Then you are. The software would insert the IP address and hash of your public key as a "torrent infohash" into the DHT.
  • Azureus DHT Same as the last one, except this is a slightly modified one for Vuze users.
  • Kademlia This network is used between eMule users. Can be bootstrapped very easily by fetching a nodes.dat file from nodes-dat.com. The software may also look for an active installation of eMule and use its nodes.dat file.
• User discovery on the same subnet Each software would listen on a specific UDP port and answer to broadcast UDP packets with its identity. The broadcast UDP packet will contain the identity of the sender, therefore a user on the same subnet may choose to ignore broadcast packets from specific identities, thus appearing offline or non-existent to begin with.
• Communication protocols The following protocols are yet to be implemented:
  • RPC-like via packet serialization Objects on both sides will be serialized with a CLR object serializer then exchanged and deserialized.
    • BinaryFormatter
    • Google Protocol Buffers
    • Apache Thrift
    • Apache Avro
    • MessagePack
    • JSON
    • BSON
    • BEncode
    • XML
• File transfers
• Voice calls
• Video calls
• Interoperability with other protocols Only open protocols that allow external connections in their specifications will be supported. No interaction with Yahoo/MSN/Skype, since those protocols are closed and require an account with their operator.
  • DCC chat with IRC users by IP
  • Chat with Jabber users
  • Call and text with SIP/VoIP addresses

Communication protocols

Plain-text protocol

This protocol was supposed to be similar syntactically to the IRC protocol. It isn't the default protocol, since it is only implemented for fun, debugging and educational purposes. A typical chat session looks like this:

HELLO RoliSoft rolisoft@gmail.com         | ->  HelloEvent, String name, String email
PING 1234567890                           | ->  PingEvent, Long timestamp
TYPNG 1                                   | ->  TypingEvent, Boolean isOccurring
MSG This is a message.                    | ->  MessageEvent, LeftoverString message
BYE                                       | ->  ByeEvent

Binary protocol

This is the smallest, fastest and default protocol. A packet looks like this:

+--------------+[+--------------+]
|  EVENT UID   |[|  ARGUMENTS   |]
|    2 bytes   |[|              |]
|     uint16   |[|              |]
+--------------+[+--------------+]

Arguments are optional, but since most of the events contain some kind of data (TypingEvent has bool IsOccurring, PingEvent has ulong Timestamp, etc) the following bytes are deserialized into an object[] instance, via a pre-mapped event-arguments-datatype list. The datatypes can be one of the following:

• Boolean – 1 byte, 0 => false, 1 => true
• Int – 4 bytes, signed 32-bit integer
• Long – 8 bytes, signed 64-bit integer
• Float – 4 bytes, signed 32-bit floating point integer
• Double – 8 bytes, signed 64-bit floating point integer
• String
  • Binary: 7-bit formatted unsigned 24-bit integer length padding + UTF-8 character sequence
  • Text: read characters until space (ASCII 0x20) is encountered unless escaped with \ (ASCII 0x5C)
• LeftoverString
  • Binary: 7-bit formatted unsigned 24-bit integer length padding + UTF-8 character sequence
  • Text: decode as string until the end of the packet is reached
• DateTime – 8 bytes, unsigned 64-bit integer representing a binary DateTime value
• ByteArray
  • Binary: unsigned 32-bit integer length padding + byte array
  • Text: Base64-encoded string representation of the byte array

Once the communication protocol deserialized the arguments into an object[] instance, the LoadArguments(object[]) method will be called on the previously initialized Event object. Once the event has been successfully reconstructed, whoever is listening on the PacketReceived event of the communication protocol will receive this object.

Supported algorithms and benchmarks

Compression

Toggle benchmark table of supported compression algorithms.

Encryption

Toggle benchmark table of supported encryption algorithms.

Hashing

Toggle benchmark table of supported hashing algorithms.

RS Chat v5 April 4th, 2014

Being in the second year of my B.Sc. studies, the Networking class had an assignment to create a simple chat application. While I could've easily turned in any of the earlier versions, I decided to implement a new one in Qt and C++.

The application has an architecture similar to the previous version. Since this application was never published outside of the class assignment, I never ended up creating a page for it and fully documenting it.