# Jasoos (Cryptography Algorithm)

I am working on encrypting and decrypt web application. I have built an algorithm that uses 24 bits long key to encrypt/decrypt the message.

Review this algorithm and please suggest anything important and fault in this algorithm that can make it perform better. Also, share the ways I can test the strength of this algorithm. Your contribution can help us to improve our algorithm.

Code is provided on my GitHub

Algorithm:-

1] 24 digit entered/generated key will be converted into ASCII code of 24 digit code.

``````public void setKey(char[] arr){
for(int i=0;i<24;i++){
key[i] = (int)arr[i];
}
}
``````

2] Entered String will be changed into a character array.

Every character will be then incremented first with the key’s value and changed into 10-bit binary code.

`````` public void Encryption(String text){
char[] msg = text.toCharArray();
int flag = 0;
int l = msg.length;
for(int i=0;i<l;i++){
int a = (int)msg[i];
// System.out.print(msg[i]+" "+a+"-> ");

if(flag>23)
flag=0;
int b=a+key[flag];
flag++;
//System.out.print(b+" | ");
String z = binary(b);
sb.append(lookUpTool(z));
//Character.toString((char)b);
}
//sb.append(sumBinary);
sb = comp1(sb);
}
``````

3] lookUp(): - It will take a 10-bit string as input and a matrix, and divide that string into two 5 bit binary code.

We will then calculate decimal value of each 5-bit binary code.

Example: 0011101101 -> 00111 = 7 and 01101 = 13

We have a matrix of 32 X 32 dimensions which has unique random values from 0 to 1023 and will not be shared publicly.

For 0011101101 we will look for 7th row and 13th column value. That value will be changed into 10 bits binary code.

``````public String lookUp(String bits, int[][] mat){

int mid = Math.round((float) bits.length() / 2);
String part1 = bits.substring(0, mid);
String part2 = bits.substring(mid, bits.length());
int row=binaryValue(part1);
int col=binaryValue(part2);;

//System.out.print("row: "+row);
// System.out.println("|| col: "+col);
int a = mat[row][col];
return binary(a);

}
``````

4] We will perform this steps ten times with ten different private matrices by lookUpTool method.

``````  public String lookUpTool(String s){

String s1 = lookUp(s,matrix1);
String s2 = lookUp(s1,matrix2);
String s3 = lookUp(s2,matrix3);
String s4 = lookUp(s3,matrix4);
String s5 = lookUp(s4,matrix5);
String s6 = lookUp(s5,matrix6);
String s7 = lookUp(s6,matrix7);
String s8 = lookUp(s7,matrix8);
String s9 = lookUp(s8,matrix9);
String s10 = lookUp(s9,matrix10);

return s10;
``````

}

## Similarly, we will do this for each character in the text/string and encrypt it.

**Examples are provided below:-

Key: c|H@yLzd3PkRte0H,u16zt8N

Message: abcd ef\$

After Encryption: 11001111000001101010000010000101101000001110100000101010111001110000011000001000

• unfortunately, we are not a decoding service – schroeder Jul 14 '17 at 10:33
• @schroeder Sorry for that, I have removed that part. But I don't know how can I find out how good my encryption is? I am sure this could be cracked, so just looking for an issue. – gauravd2196 Jul 14 '17 at 11:14
• Please tell me you are designing the cipher for fun and/or learning. For real world security, don't roll your own crypto. – S.L. Barth Jul 14 '17 at 11:27
• why don't just use already implemented crypto? this is Java code (not even a very nice to watch one) and the JVM has many builtins and the BouncyCastle library expand this to much more algorithms. Just use them and you are done. This thing seems more like a self built disaster – Serverfrog Jul 14 '17 at 12:10
• I nominated this for reopening only because I believe you need to hear from as many people as possible just how bad an idea this is, and there isn't space in the comments to describe all the failings in the algorithm. – John Deters Jul 14 '17 at 13:05

First rule of security.. don't roll your own. There are many types of analysis that will rip this system apart as it is an incredibly simple encryption scheme. I didn't bother doing a full analysis, but it appears to largely just be a substitution cipher which can be pretty easily analysed even without a known plaintext.

With a known plaintext and encrypted value, you can trivially do a known plain text attack and it will fall apart completely because it will reveal the key and allow decryption of anything else.

This is why the "don't roll your own" rule exists. It's hard enough to apply secure cryptographic algorithms correctly even when using established and extensively reviewed algorithms. Trying to make your own algorithm is an exceptionally difficult process that requires extensive review and probably millions of dollars to develop and validate.

If you are just looking for more feedback about the problems from a conceptual level, probably the largest issue is the matrixes. Your key isn't really your key. The matrixes are your key and they appear to be shared on every message regardless of key. The matrix can be trivially obtained by passing a known key in and sufficient data that all of the grids can be solved algebraically. With the substitution that the matrix offered now neutralized, we move on to the next issue.

The second issue is the way the "key" is applied. Analysing the key given the matrixes is solvable by hand as it is just a basic rotating shift cipher. Simple frequency analysis will allow trivial decoding since every 25th set will receive an identical offset from the one 25 before it. It would not be meaningfully harder than solving a cryptogram in the daily newspaper.

A big part of what makes modern encryption algorithms good is that the key and algorithm are both self-modifying. The way in which substitutions are created is altered both by the key and the plaintext such that it is extremely difficult to work backwards from the plaintext and ciphertext to the key. This takes pretty complicated math to be able to do and is why it is so difficult to both create and even to properly use encryption algorithms.

Even if certain steps aren't taken in the use of an algorithm, it can fail catastrophically. I once saw a situation where RC4 encryption was incorrectly used with no IV to distinguish different plaintexts. Because RC4 builds out a keystream from the key and the plaintext, the lack of an IV allowed trivial decryption with a known plaintext attack. All you had to do was encrypt something of similar length and get the output and then xor the ciphertexts and apply the same xor to the plaintext and you'd get the decrypted value for the same key used.

To be strong, an encryption algorithm must meet a lot of different criteria to resist analysis and building one from scratch that covers them all is notoriously difficult.

• Thank you for the thorough explanation. It helped a lot. :) – gauravd2196 Jul 14 '17 at 16:28
• @gauravd2196 - sure, wasn't sure exactly what you were trying to get at, so I tried to cover as many areas as possible. If you are generally interested in Cryptography and how it works, I'd suggest checking out the Cryptography.SE site as well. They have a lot of detailed questions about how encryption works at a much deeper level than I can get in to in a single answer here. – AJ Henderson Jul 14 '17 at 16:30