CODEWITHSUNDEEP
c++aescrypto++
Viraj
Viraj

Reputation: 797

Saving key and iv to file AES implementation Crypto++

So I am using the Crypto++ Library to encrypt a file. I need to save the key and iv for future use. I am following this tutorial. Here is my function :

void AESUtil::encrypt(string filename,bool savekeys,string savefilename){
    AutoSeededRandomPool rnd;

    // Generate a random key
    byte key[AES::DEFAULT_KEYLENGTH];
    rnd.GenerateBlock(key, AES::DEFAULT_KEYLENGTH);

    // Generate a random IV
    byte iv[AES::BLOCKSIZE];
    rnd.GenerateBlock(iv, AES::BLOCKSIZE);

    Binary b;
    string plaintext = b.decoder(filename);
    unsigned char *ciphertext= new unsigned char[plaintext.size()+1];
    ciphertext[plaintext.size()]='\0';
    if(savekeys){
        ofstream("key.bin", ios::binary).write((char*)key, sizeof(key));
    }
    CFB_Mode<AES>::Encryption cfbEncryption(key, AES::DEFAULT_KEYLENGTH, iv);
    cfbEncryption.ProcessData(ciphertext,reinterpret_cast<const unsigned char*>(plaintext.c_str()),plaintext.size()+1);
    ofstream outfile(savefilename.c_str());
    outfile.write((char*)ciphertext,sizeof(ciphertext));
}

The files contain data in �/���� format. I want to know the best method to save the key and iv programmatically which are a byte array to a file and the ciphertext which is a unsigned char* to a separate file.

Upvotes: 1

Views: 2835

Answers (3)

Wagner Patriota
Wagner Patriota

Reputation: 5684

The IV is public information. You don't need to hide it. Save it the way you want.

The KEY is what you must keep safe. To do that you may decide how much effort you want to put on it to hide it from the external factors.

  • I have some keys that I don't care to leave them as a "plain text" in the binary code. (NO SECURITY, but my mom can't figure out what to do, but a beginner in reverse engineer will laugh at it.)
  • Some keys I do a play with the bytes, like inverting parts, separating them, XOR with something. (Very unsafe, but better than nothing, a programmer with decent knowledge in reverse engineering will be able to spend some time and eventually break the security)
  • Some other cases I use 3rd party advanced obfuscation... If possible, depending on what you want, you may even replace your encryption engine with some "white-box" cryptography. Then you will have your keys very well protected. But this is usually hard/expensive. It doesn't seem to be your case. (Yes, even a very advanced assembly guru will not be happy to start reverse engineer this case.)

Another solution, if you don't need the key on your binary, is to give it to the system's password manager. On Windows, it's called "Data Protection API", and on Mac, it's called "Keychain". Take a look at these, and then you will understand why this is considered security. But it's because all the passwords here are encrypted with the "user password" so nothing is stored "on disk". A turned-off device in this scenario is considered very secure.

Upvotes: 0

Maarten Bodewes
Maarten Bodewes

Reputation: 94078

The key could be saved in a separate file. Normally the key is established between sender / receiver in advance, or it is encrypted using a public key of the receiver. Note that it doesn't make sense to save the key next to the ciphertext, as it would provide no protection whatsoever. The handling of keys is called key management and entire books have been written about it.

The IV is a different animal. The IV should be randomly generated. For CFB it should at least be unique and identical at both sides. Usually the IV is simply prefixed to the ciphertext, it doesn't have to be kept secret.

Upvotes: 1

Collin Dauphinee
Collin Dauphinee

Reputation: 14003

Your key and iv variables are the key and IV used to encrypt the plain text.

You didn't fill either; you're actually using an array filled with 0 bytes as both the key and IV for your encryption.

Upvotes: 0

Related Questions