This is a complex topic. How is security determined? Are the encryption routines (or mechanism) seemingly impossible to reverse? How well is the key is protected? How big is the key space? How safe is any communication mechanism? How safe is Facebook? WhatsApp? Signal? How safe and secure is the iPhone? And what about side channel attacks? How well does the program clean up after itself?

Alkemi uses symmetric encryption. But unlike other symmetric encryption applications, where the encrypted data is a file (with the exception of Secure HTTP), with Alkemi encrypted data is NOT A FILE (unless the user decides to save it as a file for reuse).

With Alkemi I can alkemize my message, send it out to my friends and exit the program and there's nothing left. Who are my friends? And where are they? Once Alkemi is finished, there is no more record of what it has done, unlike file encryption applications which leave a record of their work, i.e., the encrypted file. With Alkemi there is no encrypted file, just an encrypted message.

The encryption Alkemi uses was written by me starting in 2005.

The data submitted to the encryption class goes through a series of routines. There are 62 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.

I alkemized a 12000 character Original Text. That took about 48 seconds and went through over 103 million encryption routines.

But it isn't just the 103 million routines called (there are 62 unique routines). It's the order in which they are called which is as or more important.

The number of combinations is 64 to the 800856603th power. Quite a large number.

Here it is via Wolfram Alpha:

There is safety in numbers.

A large number (majority) of encryption applications rely on the Government-approved method called AES. There some others, like Blowfish, but the vast majority of encryption applications use AES.

Alkemi does not. The encryption routines (62 of them) are home grown.
In order to force decrypt Alkemized data, you would have to try all the decryption routines (62 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.

When Alkemi is through using your key, it overwrites it six times with 0s and 1s. It also overwrites the binary hash which was derived from the key (which is just text) with pseudo-random data and then a series of 0s and 1s.

There are several ways to get the original (called plaintext) data from encrypted data:

If you have the encrypted text, the program, in this case Alkemi, and the key: Just run the program with the key against the Alkemized text (called ciphertext) and that's going to work. That's how I designed it. That's the normal use.

BUT, 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. So that is:

Also, a very large number.

I do not believe there is any other mechanism available.

What this means for users is this: Even with quantum computing, billions, even trillions of times more powerful than what we have now, you could at most subtract a few numbers from those gigantic exponents so instead of 10 to the 76554th power you would have 10 to the 76500th power. In other words, no real change.

BUT, if you want to give force decryption a go, then try decrypting this:

Below is a link to a small, 2,492 byte file called challenge.txt.
It is just composed of ASCII characters.

The SHA1 checksum for this file is:

// // // File Checksum Integrity Verifier version 2.05. // e9f4d01b81d541d4211e5d0850dd9380 challenge.txt

Can you decrypt it?

Applications that are signed with a standard code signing certificates need to have a positive reputation in order to pass the Smart Screen filter. Microsoft establishes the reputation of an executable based upon the number of installations world wide of the same application. Since you haven't published your application as yet (and therefore the reputation hasn't been established as yet), the Smart Screen will continue to flag the application.

As Ronald Reagan once said, "trust, but verify."

Alkemi is signed (via Comodo). Hopefully that helps a bit.