Data Migration of Encrypted data
Published: 2022-07-07 09:57:53


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zhci7oafqlva10fz139e.png)

This blog is about the process of data migration of the encrypted data from one application to another application which uses different cryptographic algorithms, without affecting the current functionality. This requirement came into picture when I was working on the project to refactor the application from one framework to another. The old framework was having inbuilt Encryption and Decryption methods written in encapsulated classes with no access for the source code. Hence it was very difficult to **‘break the wall’** to implement the same logic used for Encryption and Decryption.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qr895gaz68zy039ucrz8.jpg)

Then I discussed the same problem with some experts. And finally after doing lots of analysis and a number of discussions, I got the solution. So, instead of breaking an existing wall, I decided to **‘construct a new wall’**, which will behave exactly the same as the old one.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hzolp8swbki48tnghq9m.jpg)

So, I decided to create an utility which will do the data migration for the Encrypted data  (like passwords and credit card numbers), but with some different **Encryption Algorithm**, in such a way that all the functionalities using the old system data or the code written for encryption/decryption will work as is, without making any modification.

After doing some more analysis on the latest cryptographic algorithms, I came across the technique which is being widely used nowadays, which is **‘Advanced Encryption Standard (AES)’**. This is a symmetric block cipher, chosen by the US government to protect the information. **Symmetric** cipher is the type of encryption, where a single key is used for both encryption and decryption. In the old system the keys were already stored for the previously used algorithm and I planned to use the same keys for the new methodology also. **Block Cipher** takes a block of plaintext and generates a block of ciphertext. In AES, it converts plaintext into a block of 128 bits and returns ciphertext as a block of the same 128 bits.

The AES algorithm uses the different key sizes based on different versions of the algorithm. So, it supports 128 bit, 192 bit and 256 bit keys for three different versions. I planned to use the version with a 128 bit key, but here I face one challenge because the length of the keys already created in the old system was not enough to create the 128 bits key, and hence in the logic I needed to add some extra characters on the run time to an existing key. 

Then I created the utility, which first takes the copy of old encrypted data in another new column, so that if anything wrong happens, I can use the backup to restore the data back to the original column, then it converts old encrypted data into plaintext using the old decryption algorithm. Then the new method with the AES algorithm converts the plaintext into a new ciphertext using a new encryption algorithm and replaces the old ciphertext with the new one. Once all data migration was done, I just needed to replace the old decrypt method with a new Decrypt method which uses AES and that’s it! Everything worked as expected!   


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eqoqpltda8xyzky4dl7d.jpg)

**Happy Reading!!**