views:

117

answers:

3

Does anyone know a c++ library that uses advanced encryption standard encryption that can achieve encryption and decryption (using counter mode) in just two lines of codes. No need of padding or buffering the plaintexts the library will take care of all this. I have had a look at crypto++, openssl and libtomcrypt but in these it seems I need to write codes to buffer and pad the plaintexts which I don't want. In brief, I need something along these lines:

ciphertext = encrypt(ctr_mode(),plaintext,key)

plaintext = decrypt(ctr_mode(),ciphertext,key)

Thanks!

+1  A: 

Ok, made a wrapper (I thought this was interesting). Important notes:

  • Make sure to use a new ivec every time you encrypt something new (but you have to use the same ivec to decrypt anything). I added a default which initializes to 0. SSH does this, so I assume it's not horrible.

  • You need to link against libcrypto and this library: g++ $(stuff) -lcrypto simpleAes.o. I included a Makefile so you can see.

I tried to paste the code inline, but it was formatting it weirdly. Find it here:

simpleAes.cpp
simpleAes.hpp
main.cpp (example)
Makefile (example)

Here's what the functions look like:

// Encrypt in with key
std::string aes_encrypt(std::string in, std::string key);

// Decrypt in with key
std::string aes_decrypt(std::string in, std::string key);

By the way, if anyone has any ideas to improve it, I'd be interested. I only did this because I've never used OpenSSL before and it looked interesting.

EDIT: I fixed the code so that it generates random ivecs and appends them to the front of the output string (so using this function, you will get random ivecs but won't have to deal with them). I updated the pastebin with the new code.

Brendan Long
Is it possible for you to be more explicit about writing a "wrapper" around OpenSSL?
I have an idea for appending the ivec to the beginning of the encrypted string, but it's not working right :(
Brendan Long
Ok so this should do exactly what you're asking for. The only thing I don't think will work is binary data.
Brendan Long
By the way, this only uses CBC mode because OpenSSL's evp library doesn't do ctr yet
Brendan Long
Correct me on this: If the encryption process is stopped half way through and CBC mode is used, half of the encrypted data cannot be decrypted but if CTR mode is used this would have been possible?
+4  A: 

I don't know how strict your requirement that the cipher text be simple AES counter mode, but Google's KeyCzar, provides exactly the kind of interface you are looking for, with more security than what you've described.

They have Python, Java, and C++ implementations available. Additionally, the library also takes care of a lot of other encryption best-practices, including some you might not have been aware of (e.g. probabalistic encryption, key versioning, etc.)

I would not lightly dismiss the extra security provided by KeyCzar. With the scheme you've described, you run into very big trouble if you ever reuse a key. So, in order to make sure you never reuse keys, you will likely have to do a lot of extra key management, which is generally considered one of the hardest parts of any cryptosystem. It's very easy to have your whole cryptosystem fall apart due to sloppy key management!

If you're interested, I can describe further the problems with re-using keys when you are using a deterministic encryption scheme like counter mode.

smehmood
I did not know about `KeyCzar` and I wish I had known before delving into `Crypto++`. My only complaint would be that they seem to have used Google Coding Standard (you have to manage the pointer yourself)
Matthieu M.
I always just avoided key re-use by generating the key randomly using a random number generator that incorporated environmental entropy.
Omnifarious
A: 

Well, perhaps I need need to worry about the key reuse but I am not convinced because the situation is as follows:

Some data of any length (data1) comes in; this is fed to the encryption algorithm. Let the secret key be sec_key. The algorithm uses the function encrypt(data1, sec_key, CTR_mode) to encrypt data1. The algorithm will deal with segmenting data1 into a specific block size (maybe I could specify it as 256) and pad if needed. I do not need to worry about these because I expect the library to take care of this.
Now, comes another data, data2. Again, we use the function encrypt(data2,sec_key,CTR_mode). I guess I don't need to worry about the key being reused because, in the end, the IV will be different each time causing the output of each block (in counter mode) to be different. For the decrypting part the same thing: We know the sec_key and the data. As we feed the ciphertext into the function decrypt(ciphertext,sec_key,CTR_mode) we obtain the original data.

Note: CTR_mode == counter mode