How to encrypt TCP data?

Not very embedded ;-)

Assuming both ends run on Windows machines, you can use the build-in crypto library. Pick any algorithem (DES, RCx, AES) and use a static key setup. I suggest to use a different IV on each packet, so they alle look different, even if the payload (your protocol message) is the same. Pad all messages to the same length, so an observer won't get additional information from the packetsize. Choose a multiple of the algorithm blocksize und use the first few bytes for IV and length.

Wim

You don't really want to mask the protocol; TCP is TCP. What you want to hide is the data.

One common technique is to use an "encrypted tunnel" or a Virtual Private Network (VPN). Google will turn up a ton-o-data on either.

And if you're -really- paranoid, have the nodes send noise to each other. That will hinder any stimulus/response probing.

G.

SSL (TLS) is a well supported and standarized encryption standard on many operating systems. Libraries are available that do nearly all of the work for you: cipher handshaking, authentication, authorization and encryption.

IPSec?

C# has many options for encryption, so I'd base my decision on the C++ side. But, of course, if you're using managed C++ you'll have all the .NET options available to you, also.

I'd look at some examples using the Windows Data Protection API (DPAPI) and see what you like from there. I tend to favor Rijndael.

These are some links that may be helpful. Google can find a lot more:

DES and TDES may also be good options.

You've got some learning to do. Setting up the keys and initialization vectors is a little confusing until you have worked with it for a while.

One big question is always: where do I store the key? I like the Windows registry because I can apply Access Control List security to the registry keys to prevent unauthorized use. By default, anything under HKEY_LOCAL_MACHINE can only be read by administrators, which is convenient if your program also runs under an admin account. If your program runs from a lower-priviledge account like a Web server account you can add Read access for that particular account.

If you don't use the registry you'll probably want to encrypt the key itself using a different technology, but please don't hard-code the key in your program.

Eric

I forgot to point out that most encryption is done by blocks. I also use this in TCP, so I blocked up my data packets and I apply encryption to each one separately. I call these my logical blocks and they are 100K bytes in size. Once it goes thru Ethernet it'll get broken into much small blocks. So when you read the data you'll have to piece together the blocks so you can decrypt the same logical block that you encrpyted.

To make the job of logical packet reassembly easier, I am sending the block size as the first 4 bytes of each logical block. The receiver gets that first, and then he knows how many bytes to expect. The last block in a transfer will often be smaller, and that's why you need a method of telling the receiver how many bytes to expect.

There are more efficient ways to do it. I wanted to make it work in a number of scenerios, and I needed to get it done soon, so I just use this methodology. I also included a flag in my common code to indicate if it should be sent unencrypted. That makes the code useful in more situations.

Eric

I've no idea what VS2005 is, but don't C# and VC++ have access to the bog-standard SSL libraries? There seem to be plenty of Google hits that indicate that they do.

Wow. Talk about re-inventing the wheel. Why not just use SSL?

It's only a few lines of code...