Results 1 to 9 of 9

Thread: Simple encryption: which algorithm?

  1. #1
    Senior Member
    Join Date
    Jan 2002

    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?


  2. #2
    Join Date
    May 2003
    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

  3. #3
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Beverwijk Netherlands
    (open)ssl (secure socket layer)

    has a good api !!

    ASCII stupid question, get a stupid ANSI.
    When in Russia, pet a PETSCII.

    Get your ass over to SLAYRadio the best station for C64 Remixes !

  4. #4

  5. #5
    Senior Member
    Join Date
    Jan 2002
    unhappyStar_7 said:

    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.

    (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.

    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.

    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.


  6. #6
    Ninja Code Monkey
    Join Date
    Nov 2001
    Washington State
    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.
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

  7. #7
    Senior Member roswell1329's Avatar
    Join Date
    Jan 2002
    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:

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

    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:

    my $Retrieved = $in{'cyphered'};
    my $linechunk = substr($Retrieved, $i, 16);
    if(length($linechunk)<1){ last; }
    $Decrypted .= $Blowfish_Cipher->decrypt(pack("H16", $linechunk));
    if(length($linechunk)<15){ last; }
    /* You are not expected to understand this. */

  8. #8
    Senior Member
    Join Date
    Jan 2002
    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.


    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.

  9. #9
    Just Another Geek
    Join Date
    Jul 2002
    Rotterdam, Netherlands
    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.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts