Summary: A program that allows 2 parties to chat to each other over a direct TCP/IP connection with ridiculously high levels of encryption which is all done in the background automatically - no central server or key management hassle required. download it here (includes Delphi source). There's a screen shot here showing an imaginary conversation between Avi and Randy.
This page is for the Windows version of the software. I have also written a Java version which is on this page. Note - the Java and Windows versions are *not* compatible with each other, i.e. you can't connect to the Java version with the Windows version or vice-versa.
Description
There are lots of programs available that allow you to chat with other people on the net. However, how do you know that nobody is snooping on your conversation? Even if a program claims to offer a secure connection, do you trust it? Is the source code available? If it uses encryption, can you trust the encryption library & examine the source code? The chat program here provides the facility to have a secure chat session with anyone else who has a copy of the program, and the full source code is provided - no library files are used anywhere. The program uses public key cryptography (the RSA algorithm) which is the standard way of establishing an encrypted connection on the internet, plus the Advanced Encryption Standard (AES) algorithm. However, all the RSA & AES implementation code is done within the main program, it doesn't use any SSL libraries, nor does it require you to manually generate a key & install it. All the source code is there for inspection so you can be sure there are no trojans or other nasty backdoors. The program generates a brand new public/private keypair every time it runs for additional paranoia. There is no preset limit on the size of the key either, simply enter the number of bits you want & the key will be generated. The default is for a 1024 bit key, but if you are utterly paranoid why not use a 2048 or even 4096 bit key? It's up to you, but be aware that large keys can take a long time to generate.
From Cryptonomicon: "Avi says: 'When you get to Manila I would like you to generate a 4096-bit key pair'...Randy is trying to generate one that is ridiculously long. He has pointed out to Avi, in an encrypted e-mail message, that if every particle of matter in the universe could be used to construct one single cosmic supercomputer, and this computer was put to work trying to break a 4096-bit encryption key, it would take longer than the lifespan of the universe."
Instructions
Suppose that Randy and Avi want to use the program to have a secure conversation. One of the parties agress to be the "client" & one agrees to be the "server". It doesn't matter who does what, but if the "server" is behind a firewall then the appropriate port needs to be open to allow the "client" to make the connection to them. Let's say that Randy is the client and Avi is the server. They both run up the program. Avi can choose the port to listen on by changing the value in the "Port" field. Avi then clicks the button "Listen" and the program immediately generates a new RSA key, then listens for incoming connections. Randy then enters Avi's i.p. address and port in the "Remote host" and "Remote Port" fields and clicks the "Connect" button. If all goes well the connection to Avi's machine is established, the encryption keys are exchanged and both programs will display the message "HANDSHAKING COMPLETED". Note that if very large RSA keys are used this can take a while. Now Randy and Avi can type messages into the "Enter message to send" field and send them to each other.
Finding your i.p. address
If you aren't sure how to find your i.p. address, this page will tell you what it is. Note that if you are behind a NAT Firewall which most organisations use you are likely to have a "private" i.p. address and it is unlikely that anybody outside the firewall will be able to connect to you, although you may still be able to make outgoing connections. To find out your private i.p. address from Windows, click Start, then Run, then enter cmd.exe. At the C:> prompt enter ipconfig and press return.
Overwriting memory for additional paranoia!
One thing I was able to do with this program that isn't possible in a Java version is to completely wipe out the memory used by the program when it exits. This is utterly paranoid but I tried to imagine a scenario where somebody was using the program and the secret police burst through the door. The user may not have time to switch off the computer (laptops can take 5 seconds to switch off) but might quickly stop the program, but leave lots of incriminating evidence in memory which the secret police might be able to analyse. Therefore, when the program shuts down it writes random garbage over all encryption keys and also clears the contents of the text windows before writing lots of garbage into them so hopefully wipes over the memory locations of your text. It doesn't guarantee to wipe everything from memory but does have a reasonable chance of doing so.
Anti-keylogging
Strong encryption isn't always sufficient to protect your communications. For example, the secret police could break into your house and install a keylogger on your computer which records every keystroke you make and uploads the details to their server. To try and provide some protection against keyloggers, the edit control where you enter your messages uses my anti key-logging component - this generates a random number of fake keystrokes for every real one so that the characters you type will be hidden among a load of garbage characters, making it very difficult for anyone to extract the real keys you typed. The remote host field is also protected with the same technique.
Compatibility
As this program is a work in progress, I may decide to change the way it transfers data from time to time. This means that later versions of the program may not be able to communicate with earlier versions. It is too much hassle for me to try and make each version backwards incompatible, so please ensure that the person you're chatting with has same version of the program as you. It is also worth pointing out that the Windows version of the program is not compatible with the Java version, i.e. you cannot connect an instance of the windows application to an instance of the Java version.
File transfer issues
Something really annoying I have found is that when transferring a large amount of data, for example transferring a file, is that some data packets seem to get lost and a lot my early attempts at file transfers resulted in a corrupted file at the other end. I'm still working on this problem and haven't completely resolved it yet. I have no idea why this happens and can only assume that this is something to do with the Delphi socket classes as I have never seen this problem in Java. It doesn't seem to affect normal chat, i.e. when you type the sentence and send it to the other person it always arrives correctly - it is only during a file transfer I have seen this problem. I found that by putting in an artificial delay between chunks of data I could reduce the chances of this happening, but this means that the file transfer takes a lot longer than it should do. You can configure the artificial delay in the wincryptochat.conf file, it defaults to 50 which means the program will apply a delay of 50 milliseconds between sending each block of data. To help protect the integrity of file transfers, whenever a file is sent the program also sends over a checksum of the file which is verified by the receiving program. I also give each packet a sequence number so that the receiving program can detect if any packets are lost.
Legal stuff: Some governments have passed or are considering laws that will require you to hand over your decryption keys if this is approved by a court of law. Well if you're using Win Crypto Chat you can't do this, as the keys are *never* written to disk anywhere! Each time the program runs a brand new RSA and AES key are generated, held only in memory and transmitted over TCP/IP (only the public key is transmitted in plaintext) to the remote party where they are only ever stored in memory as well. At no point does the program ever write anything to disk, so the AES key & RSA private key cannot be recovered.
Technical notes
Firstly, let me point out that this program uses only standard and tested encryption algorithms, RSA and AES. This is for your safety - do not trust programs that claim to have "unbreakable hacker-proof encryption", or anything with a "revolutionary new encryption technique". Refer to http://www.schneier.com/crypto-gram-9902.html#snakeoil for signs on how to spot dodgy encryption software. RSA and AES provide extremely strong crypto when used correctly and with long enough keys.
Encryption details
The program doesn't use the RSA algorithm to encrypt every message you send as this would be incredibly slow, so what it does is generate a temporary random 256-bit AES key (the AES (Rijndael) algorithm is approved by the US Government for TOP SECRET material when 256 bit keys are used). This key is then encrypted using RSA (again, using a completely new key) and transmitted to the person you are connected to. Now that both parties have securely exchanged the AES key, this is then used to encrypt the conversation. Note, you don't have to worry about all this stuff, all you have to do is enter the i.p. address of the other person and hit Connect, all the crypto stuff is completely automatic. Peer-to-peer communcation is considerably safer than chatting through a central server - you have no control over what the server administrator is doing with your messages.
Random number generation
I should point out that this program uses the pseudo random number generator called ISAAC (see http://burtleburtle.net/bob/rand/isaacafa.html ). I am reluctant to use this as I would prefer a true random generator but so far I haven't been able to find one. I considered trying to write one myself but I think this is easier said than done and any mistakes or weaknesses in the algorithm would compromise the security of the program, so for now ISAAC will have to do. It is supposed to be cryptographically secure and it has to be a lot better than the built-in Delphi random number generator.
Key generation time
For some reason the Windows version takes a lot longer to generate the RSA keys and also to encrypt anything using these keys. I was quite surprised at this because normally Delphi is extremely fast, so it must be the algorithms. It doesn't take that long to generate a 1024 bit key but larger keys can take quite a lot longer which means that the handshaking process takes quite a while.
Building the software
To build the software you will need these additional components
If you have any questions or want to report a bug please drop me a line at
