3
$\begingroup$

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?

$\endgroup$
  • 3
    $\begingroup$ 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. $\endgroup$ – kelalaka Jul 20 at 20:09
  • $\begingroup$ After the SHA512 hash, the key space would be 2^(64*8) = 2^512 bits. $\endgroup$ – Eugene Styer Jul 21 at 2:31
  • 1
    $\begingroup$ For others considering buying their product: don't. $\endgroup$ – DannyNiu Jul 21 at 12:45
  • 1
    $\begingroup$ This person seems to be equally competent in cryptography and brain surgery. Would you let him operate on your brain? $\endgroup$ – tylo Jul 21 at 13:18
  • 1
    $\begingroup$ 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? $\endgroup$ – forest Jul 22 at 8:52
9
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ I agree that there is no such thing, but it's how those ciphers are described by the author. $\endgroup$ – multithr3at3d Jul 21 at 16:33
  • $\begingroup$ even if that cipher is not broken — I briefly looked at it. It is broken by linear cryptanalysis. $\endgroup$ – forest Jul 22 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.