# Are “non-mathematical” encryption algorithms comparably secure against brute force key recovery?

I recently learned about a desktop encryption application called ALKEMI, which does not use mathematical encryption according to the website, which I understand to be a misnomer, at best:

The encryption Alkemi uses was written by me starting in 2005. It is NOT MATHEMATICAL in nature.

From what I found, it appears to be similar to, related to, or directly using libraries from Yull Encryption. The algorithm is described as using combinations of different routines:

The data submitted to the encryption class goes through a series of routines. There are 64 unique routines (procedures). The order of the routines is determined by a hash of the key. Furthermore, often certain subsets of the data is run through the routines. Routines (procedures) can and of course are reused. Typically, routines are invoked several hundred thousand to millions of times. And some routines call others which call others. The number of combinations is meaninglessly huge.

The author goes on to address how difficult it would be to recover the plaintext without knowing the key:

In order to force decrypt Alkemized data, you would have to try all the decryption routines (64 of them), in the precise reverse order.

But as you can see, the amount of routine combinations is gigantic.

There isn't enough time left in Earth's existence to try them all.

..., if you have the encrypted text and the program or even the source code but not the key, your choices are pretty limited, in my view. You have two choices: Try all the key combinations. There are a range of 217 letters and symbols, including foreign languages, and a possible 32765 of them in various combinations.

The screenshot of Wolfram Alpha shows this totalling ~10^76554.

First off, these projects raise red flags in my head for any serious use, as I fully believe in the mantra of "don't roll your own crypto". The author admits that it is a home grown algorithm, but still puts it out there recommend for public use.

More importantly to the question, I am struggling to wrap my head around how "safety in numbers" is really sufficient against a brute force key attack. My understanding is that part of the reason it is difficult to brute force a conventional symmetric encryption key (e.g. for AES) from ciphertext is that the encryption algorithm is computationally expensive, making it difficult to feasibly brute force a reasonably strong key. I didn't find a description of the 64 functions that ALKEMI/Yule uses, so I do not know how they compare in terms of compute cost, although the author says it took 27 seconds to encrypt 12000 characters.

I believe the author also claims it is secure because you can create very long keys in any charset, but regardless it is ultimately limited to the 64 bytes it is hashed to with SHA512, which I guess I can't complain too much about. But I believe this means the key space should be 2^64 rather than 10^76554.

My question is, do these (and any other?) "non-mathematical" [sic] encryption algorithms have theoretical or actual resilience to brute force of the key comparable to a modern standard like AES?

• Non-Mathematical! God made the integers, all the rest is the work of man. by Kronecker. If something is not expressible by Math either it is not tried yet or it is nonsense. Creating ciphers with a large key size is not a big problem. Remember, in Cryptography we say your algorithm is broken if we find the keys faster than brute-force even 1 bit faster. – kelalaka Jul 20 '19 at 20:09
• After the SHA512 hash, the key space would be 2^(64*8) = 2^512 bits. – Eugene Styer Jul 21 '19 at 2:31
• For others considering buying their product: don't. – DannyNiu Jul 21 '19 at 12:45
• This person seems to be equally competent in cryptography and brain surgery. Would you let him operate on your brain? – tylo Jul 21 '19 at 13:18
• Nearly all (or all) encryption relies heavily on a few instructions on the chip: XOR, NOT, ROL and ROR. These are important because they are reversible. If you XOR (eXclusive OR) a value with another value and then repeat it you will get the original value back. I'm afraid to break it to you, but that is math! Bonus: Do you notice the one operation that's necessary for security which is missing from the operations list? – forest Jul 22 '19 at 8:52

It is not hard to make primitives with massive key spaces, but that doesn't really achieve anything. One can easily construct ciphers with $$2^\text{gazillion}$$ keys that are totally insecure. This fallacy feels like a "freshman's converse" to Shannon's theorem: Perfect secrecy does imply big keys, but not the other way round!