Are "non-mathematical" encryption algorithms comparably secure against brute force key recovery?

Question

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?

Answer 1

The premise of this question is flawed: There is no such thing as a "non-mathematical" cipher. Every algorithmic procedure admits a mathematical description, hence is inherently mathematical in nature.

---

Besides that:

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!

The hard part of designing a good cipher is to make it small and fast while still achieving the desired security level. The performance figures from the linked website are ridiculously slow according to modern standards. Thus, even if that cipher is not broken — which I strongly doubt anyone has seriously studied — there is absolutely no reason to to prefer it over AES‑256.