Along with my colleagues Piyush Itankar and Namrata Singh, we developed a new encryption algorithm under guidance from Dr. B. Dinesh Rao as part of a mini project for my masters course in Embedded Systems.

This is a symmetric variable key encryption algorithm. The idea was modeled after realizing the fact that not all data needs to be encrypted with very high strength. This is a simple encryption algorithm for the tiny creatures that talk one's and zero's - IoT/Embedded ;)

For example, consider the live feed of an auction video. If we use the strongest encryption algorithm to encrypt this feed, it may 20 years for a powerful supercomputer to break the encryption through a brute force attack. However, assume that after 10 minutes, the confidentiality of the data is lost. Hence it would be waste of computational power to encrypt it with such high strength key. If encryption needs to be used in IoT or other embedded systems, a lightweight algorithm would be really worth in special situations like this.

## Design of the Algorithm

Being a symmetric encryption, it has the usual limitations. This symmetric key, is actually a collection of keys. Lets call it **Key Bank**. Key bank is an ordered collection of a *sequence* of descriptors. For example, one key bank may contain 50 descriptor sequences numbered 0 through 49. Each descriptor in a sequence symbolizes a unique operation (a permutation) you can do with a matrix (containing data to be encrypted/decrypted).

So yes, its a **block** based encryption. The size of the block in the current implementation is fixed as *9*, owing to the fact that we use a *3x3* matrix for the block operation. For efficiency, higher size may be used. But this is just a basic implementation. A formal standard does not exist yet.

In the current implementation, these descriptors are nothing but the letter *A* through *G*. *A* through *F* represent one unique permutation you can do with a 2D matrix. Finally, G symbolizes a simple **XOR** based encryption. Instead of XOR, any other algorithm can be used. Just that it has to obey the basic property of encryption like XOR. More classes of operations can be added for more randomness in the ciphertext.

When you are encrypting a file, the keybank is loaded. A string of descriptor will be chosen the first block, and the operations conveyed by the descriptor string is executed on the block serially. The factor for choosing a descriptor string can itself be another algorithm of choice. In the current implementation, we've made it *random*. This is one place where we can change the relative strength of encryption for each of the block we have at hand. Once the deed is done, the ciphertext contains the manipulated data, and the sequence index from the keybank. Thats the *Alice* part of the story ;)

At the other side, *Bob* will take the first block, take the matching sequence for that block (from the id from ciphertext), run the operations reversed, and there you have your decrypted data!

## How secure it is ?

Sadly, doing a *cryptanalysis* on this algorithm is in my Todo list. But if you have time and the expertise, please help us out!

## Rough edges

The implementation is not perfect. For example, I need to address the extra zeros that will show up at the end of the file in the deciphered text which gets introduced because of the block based encryption. ~~No big deal though, can be easily solved by adding one more field into the ciphertext and then chopping off the extra zeros, but I want to do it the least intrusive way that does not reduce the strength of the algorithm. That is why I would love to hear from the experts!~~

We're better off using PKCS7 padding scheme instead of putting anything into the ciphertext - that would be stupid!

## Give it a test drive!

The implementation is released under GPL v3, and is available at my github repo:

https://github.com/aurabindo/vaken-cli

You will find usage instructions in README.md