Reliability

Better see it yourself first: http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html

Some people ask me, how reliable it is and why I don't use approved algorithm. A "really professional" guy, on an encryption mailing list, full of "Security Gods"(One of them wrote me privately and he was the head of cryptology chair on a reputable US Univesity for example), asked me "why don't I use DES for example. What is the difference, why is it more secure?"

Here is why. Let's have a key body of just 128 random bytes, and 3 as the number of jumps. Forget the key body length now. For "every transaction", we send 8 bytes of Salt(or nonce) data unique for that transaction! Which adds 2^64 complexity. For every transaction, we also use 4 byte of crc key checksum data. Which adds 2^32 complexity. Which makes, 2^96 as the lowest limit for any meaningful attack. Because, anytime, any bit of this values change, entire "jump path" and the "entire" ciphertext will be different! Those are the essential parameters besides key body elements for each byte to be encrypted! At least 2^96 complexity brute force attack is necessary just to make any meaningful analysis. Not breaking! Just for being sure to having eliminated the random data added to every encryption&decryption process.

Hey! We don't take the key body into consideration yet! That was just for the randomness we add to encyrption for each operation. And huh! Even without taking key body into consideration; we are above the security level provided by DES; which has 2^56 complexity for brute force attacks and approved by "authorities" to protect sensible data unce open a time!

Now, we have 2^96 brute force algorithmic complexity just to know "the jump starting point"! Again! Without taking into consideration key body! Just to start to a "meaningful attack"!

Considering we have only the key body, for every byte to be encrypted, there are 128 * 128 * 128 possibilities to obtain the number to be finally XORed with plaintext byte! And every time we encrypt a byte from plaintext, we encrypt a byte from key body!

When the "analyze" begins: I don't want to give huge numbers, but the rest of analyze, considering 128^3 possibilities on key body, for every byte encrypted, seems "enough hard". Am I wrong?

If you want me to give a number: The brute force attack complexity to break this algorithm is: 2 ^ 64 * 2 ^ (KeyBodyLen * 8) for key: 2 ^ 1112 for 256 bytes key body length.

Wikipedia says that the most powerful computer of the world today, can break 56 bit DES bit brute force in 399 seconds.

Again, without taking key body into consideration, in order to give a robust number to compare: Just to find out our "initial jump point and first XOR value" attacker must try 2^96 possibilites which needs : (399 * 2^40)/(60 * 60 * 24 * 365) = 13,911,248.7152 YEARS! Just to start to a meaningful analyze! Not breaking! Only after trying that much combination, the attacker can make some assumptions about the results he will obtain from the analyze! And every byte to be analyzed will multiply this number by KeyBody^NumberOfJumps!

As I told you, I am not an expert. I don't claim it is "impossible" to break.But those are the base numbers. I may be wrong. And this is a public place. Correct me if I am wrong please! I just tell, for example, for my specific needs in a chat application, where the keys are not used for a very long time, it seems enough. Each user pair will use 4 jump level keys with 256 byte key body for their private chats. I think, it is fairly enough. It is up to you to decide. Take your own risk! Think carefully when to use, where to use it! All I can do is to share my ideas transparently.

There isn't any specific precautions against side channel or any physical type of attack. You must take care of your phone or computer. Physical attacks are usually applied by Intelligence Services for highly suspicious persons; it is not my concern, -and I don't want- to protect this kind of people. Even if they are innocent, they can use another algorithm. My goal is to prevent technical surveilance of ordinary people in order to protect their personal privacy; not to protect criminals. Intelligence services don't spend resources to physically follow anyone without reasonable suspicion. Even if they do, I don't want to confront with Intelligence Services for criminals. Even trying to block their "technical surveilance of ordinary people" is a "dangerous act".

So far, we detected a "unique" vulnarability, which can be "theoretically" defended by the "Crypto Experts": Intercepting both the plaintext AND the salt(nonce). But we consider it only "theoretical" because, key's original salt value is only used to encrypt&decrypt salt values to be transmitted with each ciphertext. Salt values are random by nature. If someone claims this "theoretical possibility", he must also explain us "how" he can intercept the nonce value! But anyway, a "theoretical possibility" is still a threat and you must consider this possibility in your real life applications.

But, we have also found a way to turn this "theoretical disadvantage" into a "practical advantage", by changing "Key's original salt value regularly". We will elaborate this in detail; later in the documentation(Sorry the documentation is still incomplete).