Sorry, this is slightly off topic for this form as far as embedded is concerned, but still...
I have two components talking to each other over a pair of sockets. Application protocol information in sent as TCP messages in "clear text". Is there an easy way to implement some basic level of encryption, so that someone listening on the ports and looking at the data would not be able to make out what the application protocol is?
One component is written in C# and one in VC++ (both VS2005).
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.
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.
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.
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.