Reply by Grant Edwards●September 6, 20072007-09-06
On 2007-09-06, Eric <englere_geo@yahoo.com> wrote:
> On Sep 6, 5:09 pm, Eric <englere_...@yahoo.com> wrote:
>> On Sep 4, 12:32 pm, ElderUberGeek <aribl...@gmail.com> wrote:
>>
>> > One component is written in C# and one in VC++ (both VS2005).
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.
> 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.
[...]
Wow. Talk about re-inventing the wheel. Why not just use SSL?
It's only a few lines of code...
--
Grant Edwards grante Yow! HELLO, everybody,
at I'm a HUMAN!!
visi.com
Reply by Eric●September 6, 20072007-09-06
On Sep 6, 5:09 pm, Eric <englere_...@yahoo.com> wrote:
> On Sep 4, 12:32 pm, ElderUberGeek <aribl...@gmail.com> wrote:
>
> > One component is written in C# and one in VC++ (both VS2005).
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
Reply by Eric●September 6, 20072007-09-06
On Sep 4, 12:32 pm, ElderUberGeek <aribl...@gmail.com> wrote:
> One component is written in C# and one in VC++ (both VS2005).
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:
http://fp.gladman.plus.com/cryptography_technology/rijndael/http://www.eggheadcafe.com/articles/20050814.asp
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
Reply by The Real Andy●September 5, 20072007-09-05
On Tue, 04 Sep 2007 16:32:08 -0000, ElderUberGeek <aribloch@gmail.com>
wrote:
>
>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).
>
>Thanks
IPSec?
Reply by Ico●September 4, 20072007-09-04
ElderUberGeek <aribloch@gmail.com> wrote:
>
> 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).
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.
--
:wq
^X^Cy^K^X^C^C^C^C
Reply by ●September 4, 20072007-09-04
On Sep 4, 9:32 am, ElderUberGeek <aribl...@gmail.com> wrote:
> 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).
>
> Thanks
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.
Reply by Wim Ton●September 4, 20072007-09-04
"ElderUberGeek" <aribloch@gmail.com> wrote in message
news:1188923528.873074.182810@w3g2000hsg.googlegroups.com...
>
> 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).
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
Reply by ElderUberGeek●September 4, 20072007-09-04
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).
Thanks