Here's the challenge:

Below is a link to a small, 14K, file called **challenge**.

It is just composed of ASCII characters.

The SHA1 checksums for these two files are:

```
//
// File Checksum Integrity Verifier version 2.05.
//
836ae413481b21d49fa5a9cefe1304c8 challenge
```

Perhaps my inability to figure out how one would decrypt this file without all the parameters only shows my ignorance of cryptography.

With Yull I have strived to make it easy to protect your data and near impossible for an adversary to retrieve it without your cooperation.

I think I have succeeded, but of course, I cannot prove a negative.

You can read the White Paper here on the web site to learn how Yull works. Perhaps that's some help.

**PROVE ME WRONG! SHOW ME YULL IS A FAILURE!**

I will answer questions (if they are useful for the rest of the community) about these files.

$100 to the first person who can email me the correctly decryted file challenge.

Recently (as of 7/28/2019) a short discussion of Yull was brought to my attention.

It can be found here:
Are " non-mathematical" encryption algorithms comparably secure against brute force key recovery?

The consensus is that my encryption routines are not secure and it would be easy to get the plaintext and key from Yull-encrypted files.

Another valid criticsm is my use of "non-mathematical".
I wrote that many years ago out of naivete and never thought about it again.

Of course encryption routines use `XOR`

and `ROR`

etc and that is mathematical. I have corrected that.

One criticism I know is correct is that the times posted for Yull are VERY SLOW.

I've since (in Alkemi) changed how that works. The time to encrypt is much much faster and I'm working on improving that as well.

Of course all that is moot if the encryption mechanism is junk.