what algorithm to choose
faf...@gmxpro.de
I wonder if anyone here could point me in the right direction. My question isn't directly Crypto++ related, but I may end up using it to solve my problem. I'm not a cryptography expert.
I'd like to implement a secure communication over TCP/IP or UDP between two of my applications within a local network. I got the client/server part all written and working, talking back and forth. However, I need to encrypt the contents of these messages to make them tamper-proof. Typically these are just a few bytes every few minutes. Setting up an SSL connection is not an option, so I need to encrypt them at the source level.
I'm willing to read up on this, but before I choose an algorithm and implementation, can you comment on how to do this in a secure and effective way?
Thanks in advance,
Fafa
faf...@gmxpro.de
Timestamping is probably not necessary, as these are just short messages which are responded to immediately and then discarded. And on the transport side, I can handle out of order packets fine and simply wait until all packets have arrived before decrypting the received buffer.
As I have full control over the source, I could put a key in both apps, if that's a safe way to do it.
The packets will not be routed outside of the local subnet, so my primary concern is not "internet grade" encryption.
- Fafa
-------- Original-Nachricht --------
Datum: Mon, 26 Jun 2006 13:12:27 -0400
Von: Frank Palazzolo <pala...@comcast.net>
An: faf...@gmxpro.de
Betreff: RE: what algorithm to choose
>
> Hi,
>
> Do you need to encrypt them (protect from readability) or make them tamper
> proof (hashing/signature?) or both? Do you need to detect corrupted
> messages and out of order or old messages? Do you care if there is a key
> in
> the client or server, or both?
>
> I might have some ideas for you. I have used Crypto++ to do something
> similar in the past. I ended up using something like AES/CBC and MD5 or
> SHA
> to both encrypt and "sign" (encrypt a hash) timestamped credentials, for a
> web application. My goals were protection, tamper-proofing, small message
> size. It was cool in that the timestamping allowed me to avoid writing a
> session manager.
>
> Keep in mind, everything in SSL is there for a reason.
>
> Thanks,
> Frank
Michael Monsen
> Hi everyone,
>
> I wonder if anyone here could point me in the right direction. My question isn't directly Crypto++ related, but I may end up using it to solve my problem. I'm not a cryptography expert.
>
& Bruce Schneier.
> I'd like to implement a secure communication over TCP/IP or UDP between two of my applications within a local network. I got the client/server part all written and working, talking back and forth. However, I need to encrypt the contents of these messages to make them tamper-proof. Typically these are just a few bytes every few minutes. Setting up an SSL connection is not an option, so I need to encrypt them at the source level.
>
makes the message unreadable to a third party. If you are only
interested in making the messages tamper proof, then what you need is a
MAC (which stands for Message Authentication Code) of the data so that
you can verify the integrity of the message. If you also want the
messages to be encrypted, you can do both -- generate a MAC (or HMAC) of
the data, then encrypt the data along with the MAC so that after
decryption, the MAC can be verified and data integrity ensured.
> I'm willing to read up on this, but before I choose an algorithm and implementation, can you comment on how to do this in a secure and effective way?
> Thanks in advance,
>
They are for verifying data integrity. Then read about symmetric
encryption if you need to keep your messages secret. The algorithm you
choose will depend greatly on the amount of security you need. AES
would be one obvious (and standard) choice. Once you've settled on an
encryption algorithm, you'll need to decide whether you need to worry
about replay attacks (where an attacker injects previously sent packets
into the data stream) and if so, decide how you will handle them. One
way would be a simple serial number on each message that is incremented
each time a message is sent. You can probably think of others that
would be more appropriate for your particular situation. Another attack
would be if an attacker is able to remove a message from the stream, how
will you handle the case where an expected packet never arrives?
The next thing to look into would be Diffie-Hellman key negotiation
to help you establish an encryption key for either AES or your HMAC
algorithm (or both.) While you're reading about that, pay special
attention to Man-in-the-middle attacks and decide whether it is
something that you need to concern yourself with. If it is, then you'll
need to research methods for preventing that kind of attack. Of course
there are also alternatives to Diffie-Hellman, it is just one of many
different ways to establish a key.
At any rate, doing all of these things again will depend on the
kinds of threats you wish to plan for and how thorough you want to be.
Some of the things I've mentioned here may not even be necessary for
what you are trying to accomplish. I also may have left things out. I
do not consider myself an expert, but I do have experience with setting
up encrypted communications between nodes on a network, so I hope that
what I've written here will be of some assistance.
Good luck.
--
Michael Monsen
There are two rules for success in life:
1. Don't tell people everything you know.
Frank Palazzolo
Hi,
Do you need to encrypt them (protect from readability) or make them tamper
proof (hashing/signature?) or both? Do you need to detect corrupted
messages and out of order or old messages? Do you care if there is a key in
the client or server, or both?
I might have some ideas for you. I have used Crypto++ to do something
similar in the past. I ended up using something like AES/CBC and MD5 or SHA
to both encrypt and "sign" (encrypt a hash) timestamped credentials, for a
web application. My goals were protection, tamper-proofing, small message
size. It was cool in that the timestamping allowed me to avoid writing a
session manager.
Keep in mind, everything in SSL is there for a reason.
Thanks,
Frank
-----Original Message-----
From: faf...@gmxpro.de [mailto:faf...@gmxpro.de]
Sent: Monday, June 26, 2006 12:25 PM
To: crypto...@eskimo.com
Subject: what algorithm to choose
ls+pelcgbcc-yvfg-erdh...@ggtcorp.com
> inserting spoofed packets is probably the biggest concern.
The biggest converns are `date' command and
commands which allow to change `host ID'.
--
If God is One, what is bad?
-- Charles Manson