SwarmApps Code Blog

November 24, 2009

A simplification wrapper for the Crypto++ library

Filed under: c++, Cryptography — Tags: , , , , , , , , , — swarmapps @ 2:07 am

While working on a client-server based app, I suddenly came face to face with the need to secure and authenticate certain commands between the client and server.  I was certain there was a library out there to meet my needs and I was right.  I rapidly came across the Crypto++ library, a powerful set of cryptographic tools written and tested by experts.  I was in heaven!  Think of the time this has saved me!

There was only one problem.  The Crypto++ library is indeed a very powerful set of cryptographic tools, but I found the learning curve to get my first apps running with it to be very high.  I examined all the sample code I could find, worked through the API documentation, and examined the validation and test code before I finally started catching on.  Then I had to “grep” my way through the files to identify which headers I needed to include for a given function.

DISCLAIMER: All of this brainache is undoubtedly due to my own lack of skill and formal training.

Nevertheless, I overcame my deficiencies and learned how to encrypt and decrypt at will.  But, I was unhappy with the amount of extra code I had to put everywhere I wanted to encrypt and decrypt something.  So, I ended up writing a simplification wrapper to make my work easier.  My wrapper uses only a small subset of functionality and algorithms in Crypto++, but it makes using that subset very easy.

As a very small example, here is how you encrypt a given plaintext string:

string cipherText = BasicCryptoPPWrap::EncryptStringAES(“Encrypt me”, key, initVector, errFlag, errMsg);

The wrapper also implements a custom Advanced Encryption Standard protocol that stores the initial vector with the encrypted data, so you don’t have to track it yourself.  I have used this wrapper very successfully in my own work, I think you’ll find it useful too!

Wrapper functions:

  • Implements symmetrical AES encryption and decryption
  • Hex encoding of binary data
  • Hex decoding of hex-coded strings
  • Generic string and file encryption
  • Custom protocol string and file encryption
  • Random bit and byte generators
  • SHA-256 Hash generator

The wrapper is not a standalone solution.  It requires your code to link to libcryptopp and know where the cryptopp header files are found.  The Crypto++ website can help you set up your system.  Once you get the validation suite to run successfully, you will be able to use this wrapper.

Get the files here:

  • BasicCryptoPPWrap.h – The header file that makes it all happen
  • example.cpp – An example file that takes you through all the functions available in the wrapper

Good luck!  I release this wrapper into the public domain, but if you happen to use the code I wouldn’t mind hearing about it!  Credit might be nice too!

Mike

Advertisement

8 Comments »

  1. I found a small Problem in your code when compiling under VC++ (Probably works fine on Linux in gcc etc.), I’ve made a correction to your code and submitted it here: http://pastebin.com/f2fc53f83

    the changed line is

    byte block[howManyBytes]; to byte* block = new byte[howManyBytes];

    Comment by Aaron Polley — January 28, 2010 @ 9:49 pm

    • Thanks Aaron, I don’t use VC++ at all in my work so I didn’t run across that. Is there a problem then with a memory leak? There’s now an explicit new called without and explicit delete.

      I appreciate the comment!

      Mike

      Comment by swarmapps — January 31, 2010 @ 1:18 am

      • Your right there is now a memory leak (I think i must have been half asleep to have missed that), anyway I’ve fixed the memory leak, you now have to call cleanup() once you have finished using the data generated by bytegen(). new copy here http://pastebin.com/f65afc19d and a updated copy of the example that uses cleanup(), http://pastebin.com/f659b9666

        It works by keeping a array of pointers to all of the memory allocated, and then deallocating all of that memory when cleanup() is called.

        Let me know if you see any other problems.

        Thank you.

        Comment by Aaron Polley — February 3, 2010 @ 11:15 pm

    • I found a small problem, really isn’t a problem in your code but how my code uses your code.

      In the method MRDecryptStringAES if inputed text is less then 16 bytes then cipherText.assign(ivAndCipherText, 16, string::npos); will crash the program.

      I added a check before anything happens in the method:

      if (ivAndCipherText.length() < 16) {
      err = true;
      return "Inputed text is too short";
      }

      My program doesn't have control over what goes into the method so I need to add more checks.

      Comment by AdamMagaluk — July 8, 2010 @ 7:51 pm

      • Hey thanks for the error checking code!

        I guess I never considered that since the MRDecrypt_X_AES functions are supposed to work on strings and files with a 16-byte initialization vector prepended to them; so I figured you couldn’t go below 16 bytes in the input to the function.

        Glad to know you found it useful.

        Mike

        Comment by swarmapps — July 9, 2010 @ 2:00 am

  2. Your welcome, yes my app required me to take any input. It was causing a error I could not find in my code.

    Comment by asam magaluk — July 9, 2010 @ 4:39 am

  3. thanks a lot
    your code worked for me
    i am using it for aes , blowfish and des
    just changed cbcmode’s algos to other modes like des, blowfish etc

    i wanted to ask , the encrypted file sink size is same for all algo though data is same
    please help is it correct or i made some mistakes

    Comment by techsurge — September 11, 2010 @ 9:11 am

    • I’m glad you found it useful and were to extend the code!

      I’m not sure I understand your question. Did you mean to say the file sink size is different for each algorithm even though the data is the same? If so, then it probably has something to so with the blocksize of each algorithm. In block mode, the encryption protocols usually work in set block sizes. If the data won’t make it to the end of given block, the data is padded to make it to the block size. For example, in AES, the blocksize is 16 bytes (I think). Therefore, every encrypted file built by the algorithm is wholly divisible by 16. Each algorithm might have a different blocksize, resulting in different file sizes. Check the documentation on the crypto++ website.

      As the disclaimer in my code states, I am not an expert in cryptography. You will certainly find more talented folks on the Crypto++ website to ask.

      Mike

      Comment by swarmapps — September 12, 2010 @ 1:26 am


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Theme: WordPress Classic. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.