Simple encryption: which algorithm?

Hi all.

I'm looking for a simple, fairly secure, symmetric algorithm with an easily interfaceable implementation in C or C++, to encrypt/decrypt packets in a simple client/server app I'm making.

It doesn't need to be amazingly secure, just secure enough that casual inspection of the packets won't yield anything useful (i.e. to stop kiddies from sniffing it)

I am happy with using a symmetric key, which will be distributed to the client by some reasonable means. The key size doesn't matter that much to me - I imagine 128 bits will be plenty.

Performance is not that important as it will be fairly low-bandwidth.

I am not sure what algorithm to use, there are a lot floating around.

Any suggestions (ideally with links to src code) would be helpful.

I am not very familiar with cryptanalysis. If I encrypt all my packets with the same symmetric key, and their contents are very similar, is that going to provide attacks?

Because I may use unreliable transport, state must not need to be maintained between packets, as there is a possibility they may be missed. Essentially the cipher will be reset for each packet (although this may be a weak thing to do also). I guess that adding some random junk near (or at) the beginning of the data to encrypt will make it more secure?

Thanks
Slarty

my advice is to create your own... i know that it's not much of an advice but if you want somthing simple use C's XOR function w/ some addtional obfsucation of your choice... not hard at all

(open)ssl (secure socket layer)

has a good api !!

http://www.openssl.org/docs/ssl/

blowfish
http://www.santsys.com/Source/Encryption/Blowfish/

AES
http://fp.gladman.plus.com/cryptogra...logy/rijndael/

RC2
http://libtomcrypt.org/src/html/rc2_8c-source.html

RC4
http://www.cr0.net:8040/code/crypto/rc4.php

twofish
http://libtomcrypt.org/src/html/twofish_8c-source.html

unhappyStar_7 said:

Quote:

---

my advice is to create your own... i know that it's not much of an advice but if you want somthing simple use C's XOR function w/ some...

---

I don't want to create my own because I cannot create a secure cipher myself, I do not have the PhD in maths required to even begin to know where to start.

No, XOR ciphers are not even slightly secure, the most basic cryptanaysis will crack them.

the_JinX:

Quote:

---

(open)ssl (secure socket layer)

has a good api !!

---

I'm sure it does, but you misunderstood my question. I don't want to be bound by the protocol of the ssl API. I am implementing my own protocol. I only want a cipher not a whole protocol suite.

I also don't want to pull in 100s of k of unnecessary code.

|The|Specialist:

Quote:

---

ctually you'd need Xor and alot of other stuff too deppending on what you plan on doing...

---

Actually you misunderstood me even more than anybody else.

I don't want to implement my own cipher because I cannot do so securely, I simply don't have the years of maths training.

You obviously don't understand encryption if you think that such a simple approach can yield decent security.

Quote:

---

Ucase can be used to change a string to uppercased ASCII

---

You clearly misunderstood me:

1. I said I wanted to use C. Ucase, Asc, Chr are all Visual LameBasic ****.
2. How is changing a string to uppercase at all related to cryptography?

I never specified that my data would be ascii. Even if they are, who says I want them converted to upper case?

black_death: Thanks, your opinions on them would have been helpful.

Top contenders at the moment are blowfish and twofish - the only problem is that they are block ciphers and only work on data that is a multiple of the block size. However maybe I can adapt the protocol to compensate.

Slarty

Actually xor encryption with a nice one time pad is fairly hard to break. It all depends on what you use to xor your information with.

slarty -- I recently had a need for the same thing, only in Perl. I used blowfish for that along with a simple algorithm that took 16 characters from the string to encrypt at a time, unpacked it into hex, and fed it through the blowfish module. If you know anything about Perl, this should make it a bit clearer:

Quote:

---

my $i=0;
my $Blowfish_Key = $in{'key'};
my $Blowfish_Cipher = new Crypt::Blowfish $Blowfish_Key;
my $Password = $in{'password'}
my $Encrypted = "";
my $Decrypted = "";

for($i=0;$i!=-1;$i+=8){
my $linechunk = substr($Password, $i, 8);
$Encrypted .= unpack("H16",$Blowfish_Cipher->encrypt(pack("A8",$linechunk)));
if(length($linechunk)<7){ last; }
}

---

I'm afraid I don't know much about a C translation, though. When decrypting, I just did the reverse:

Quote:

---

my $Retrieved = $in{'cyphered'};
for($i=0;$i!=-1;$i+=16){
my $linechunk = substr($Retrieved, $i, 16);
if(length($linechunk)<1){ last; }
$Decrypted .= $Blowfish_Cipher->decrypt(pack("H16", $linechunk));
if(length($linechunk)<15){ last; }
}

---

Quote:

---

Originally posted here by Juridian
Actually xor encryption with a nice one time pad is fairly hard to break. It all depends on what you use to xor your information with.

---

I believe that :)

But unfortunately it won't be using a one-time pad.

roswell1329:

I might just do this. I have downloaded several blowfish implementations off the net and it seems they aren't *too* complicated. Anyway the only minor problem is that they work 8 bytes at a time.

However I can change my format to include a length byte and pad the message with random stuff.

Previously I didn't need a length byte as the packet length was always correct.

Slarty: Be careful when implementing your own protocol. Using a flawed protocol can still leave you vulnerable. Remember WEP? WEP has decent encryption but the protocol is flawed.

I say stick to known and proven protocols.