Yull Encryption
by Ronald Gans
The core of symmetric encryption programs is the encryption routine itself.
Most programs do not create their own encryption routine, but instead use one of several routines that have been vetted and approved by the U.S. government and academic cryptographers. You can download these routines like AES or Blowfish, along with others, and examine them yourselves. They are fairly easily to incorporate into your program, so with a moderate degree of programming skill, you can almost write your own government-standard encryption program. Perhaps.
Yull doesn't use AES. For Yull, encryption is handled in two parts which relate to each other. The first is the setup, handled by the Yull class. Besides validating parameters and files, it utilizes eight options to determine how the file is encrypted or decrypted, as you will read below. Once the setup, which is fairly complex, is completed, the reads are submitted to the encryption class, Andromeda. One of Andromeda's 60 routines is Blowfish, but the rest are written by me.
One of the bases of modern cryptography is Kerckhoffs's Principle, which states that "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." (Wikipedia).
But if the size of the key is fixed or within a small range, the integrity of the system might be compromised, as that might be useful information as to which file is the key. In fact any information about the system you use is useful to the enemy. For instance, Blowfish, a popular encryption protocol, uses keys up to 448 bits, or 56 bytes; AES, the government-approved standard, uses a key up to 256 bits or 32 bytes, so that is definitely some help when trying to narrow down the range of likely keys. This key space, which is used in most other encryption programs, is not very large; and even if it is relatively immune to a brute force attack today, the trend is not good. If the key is stored on a disk, knowing the size or the size range might narrow down the key possibilities, assuming that the enemy has access to the entire contents of the disk. But if the key were not the key, that might make a difference. And with Yull, that is the case.
Also, with AES, the encryption system most commonly used, you know the rounds (the number of times the data goes through the encryption routine) are between four and 20. According to the Wikipedia page for AES, it's ten cycles for a 128-bit key, 12 for 192-bit, and 14 for 256-bit keys. Yull uses a variable number of rounds ranging from one to 150.
Other encryption programs, mainly those which rely on AES, add a fixed amount of dummy data, so you might also figure out how much dummy data is added. Also, the files are not read out of disk order (to my knowledge; I think Yull is the only encryption application which does this).
Basically, the more predictable and reliable your encryption system is, the weaker it is.
Why Yull is Different
First, the size of the Yull key is not fixed. It can be any file between 100 and 10,000 bytes. It could be a Word file or a text file or a system file. Yull encrypts the key internally during runtime before using it, so the randomness of the key is not an issue (but of course, the more randomness the better). Yull gives you the option to create your own keys, but you don't have to. So with Yull, without additional knowledge it is impossible to even guess the size of the key, let alone where it is. Yull can create the key if you want, but you can also select the file yourself.
Second, unlike other applications (I have done a brief survey of them but I can't validate this is 100 percent correct - just seems that way), Yull's encryption mechanism depends not only on the key, but also on eight options:
Users, by setting the options, can influence, but not determine, the values Yull uses:
- The minimum and maximum size of the read buffer used.
- The level of encryption.
- The minimum and maximum number of rounds in the array of rounds.
- The amount of dummy data added.
- The order the reads are made.
- The personal data (a type of initialization vector for the key).
Now these might not sound like much, but numerically they are important in putting brute force decryption way out of range.
The Array of Rounds
The rounds (the number of times a read buffer is submitted to encryption) range from one to 150.
If a file is 10,000 bytes long and the read size is 100, there are 100 reads. And with 100 reads, what are the rounds?
There are 149,100 (or 2.082701e+217, which is 2.08 * 10217) possible combinations to try, a number way too large to be meaningful.
So, in order to brute force decrypt the file, you would have to try that many attempts, for starters.
The Read Order
Yull does not read the file in disk order.
That is to say, it will determine the read order once it knows how many reads there will be.
If there were two reads, there would be two possible read orders (2! or 2 factorial, which is 2 * 1).
If there were ten reads, there would be 10! (3,628,800) possible read orders (10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1), and if there were 50 reads, there would be 50! or 30,414,093,201,713,378,043,612,608,166,064,768,844,377,641,568,960,512,000,000,000,000 possible combinations of reads.
So if you knew somehow there were 50 reads, you would be facing that number of decryption attempts, but times the number of array combinations (14950).
Read Buffer Size
This is a value between 20 and 600. If you did not know the read buffer size, you would have to try all of the numbers that fit, between 20 and 600.
If your file was, say 10 kB in size (10,240 bytes), you would have to try all of the combinations where the read size is 20 (512 possible reads, which means 512!, a number too big to print on this page), up to the read size of 600, along with all of the other combinations of values.
And you have to do it backwards. You have to exactly mimic the decryption mechanism. You would have to brute force duplicate decryption. It is physically impossible, regardless of how many quantum computers and GPU arrays one uses.
Dummy Data
Yull will always add dummy data to the read buffer.
Yull will prepend between 20 and 100 bytes of dummy data (that is, pseudo-random data) to the read, and then encrypt that with the real data. The dummy data is generated with each read, so it is not the same each time. At the end of the encryption, the dummy data is scattered in with the actual data.
Personal Data
Even if the enemy figures out your key, your key is encrypted with your personal data, a 200-character text string which is like an initialization vector.
While this can be stored in the options file and the options file can be encrypted (that key is not stored anywhere), you can also elect to not store this anywhere and Yull will ask you for it when it needs it. So even if the enemy guesses your key, they also have to guess a possible 200-character-long ASCII string of personal data.
There are 247 possible values (if you enter them via Alt+#) you can use for your personal data. That's all of the normal ASCII characters (including the space) along with most of the 128 values above 127. You would enter those via your numeric keypad Alt+ two or three digit value.
This gives you 247 possible characters and, with 200 characters for the personal data, you have something like 247200 or 3.4625 * 10478 which, like most of my other numbers, is way too big to imagine.
More than all of the nanoseconds left in Earth's existence. Its size is almost meaningless except in this context: by numbers alone it is impossible to decrypt by force. You can also use Alt+0+three digits. This maps the output to the ANSI character set rather than the IBM/OEM PC extended ASCII character set. (Note: Yull does not recognize Unicode; to Yull they are just bytes in a file.)
But you do not have to store this data in Yull or in the options file. You can check the "Ask For PData" check box and Yull will ask you for it at run time and never store it.
Or you can use no personal data at all and Yull will automatically create that for you, again, only at run time. Yull uses a very long string of values which is in turn used to create a SHA-512 hash which is in turn used to encrypt the key. Again, only at runtime, never stored anywhere.
The Key File
Yull can use any file it can read as a key as long as the file is between 100 and 10,000 bytes long. If you want to keep which file you use as key secret, you can instruct Yull to ask you for it at runtime.
Encryption
The encryption class (Andromeda) uses both block and stream ciphers.
Block sizes are key-dependent; some blocks are derived from non-contiguous bytes (from the read buffer); byte streams may be treated as bit streams (that is, ROR and ROL on a byte stream converted into bits).
Yull uses 60 encryption functions, which are called based on the key (see the Andromeda section below). So if the read buffer were 20 bytes long, there would 6020 or 3.656158440062976 * 1035 possible combinations of routines.
And if the read buffer were 600 bytes long, there would be 60600 possible combinations, which is another number way too large to be meaningful, putting brute force decryption way out of range. But, in case you're curious, there are this many combinations:
777589218222736384636522430337386634590960260474997497930551953670885124059582511915276363055927956191476258211968698749794062201796468994358639583677597277966221496081386040428524624036837389354858526340\ 577092567712992303800988224660801420011590301566623771381690916610533780273061591405886984010445315178061205744446474529826087599676191924470372419816391019296687161848319000324789980278116093440553336474\ 885337114594869911104052877511222356822422718874052733173760000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\ 00000000000000000000000000000000000000000000000For most (or all) other symmetric encryption programs, if you have the key, the encrypted file, and the program itself, you can get the plaintext.
But with Yull, that is not enough, as Yull also requires that all the options are correct. And where are the options stored? Yull lets you store them in external files, but you don't have to. They could be stored on a piece of paper in a drawer if that seems best. They can be encrypted and that key is not stored anywhere.
Yull does far more work than other encryption programs. It is somewhat slower and, with the encryption level set to MAX, it could be quite a bit slower. However, if it takes, say, three seconds to encrypt (and decrypt), that is actually an additional safety feature in that brute force will take too long, more time than the Earth has left.
If you have the key and the encrypted file, you will still not have any way to guess the read buffer size (and hence the number of reads) or the number of rounds for each read; nor will you know the amount of dummy data added to each read. With the key and the program and source code, you might be able to narrow down the read order, but that's all.
By encrypting many times and with various combinations of the 60 encryption routines in Andromeda (the encryption class), it is common for Yull to encrypt a file with tens of millions, hundreds of millions, even hundreds of billions of encrypts. So, not only is there an enormous number of option parameter combinations running to unimaginably huge numbers, there are also a possible several hundred billion encrypts (and decrypts) which, without the options and the key, all have to be tried in the correct order.
The option values, which help Yull determine the read size, the dummy data amount, the read order, the rounds array, and how the key is encrypted with your personal data are stored (if you want) in an options file. This file can be encrypted as well, but the key for the options file is never stored.
What Kind of App is Yull?
Yull Encryption Pro is a .NET 4.0 application written in C# using Visual Studio 2012.
The executable, YullG, is a Windows-based, GUI application. YullG has three major components (classes) and a few minor helper classes. The first one is the UI (user interface class) which handles user input, hosts the controls as WinForm controls, performs validation, manages options, and so forth. Yull.exe is a console application, which does everything YullG does, but as a console app which can be called by a batch file or a PowerShell script, for instance, as a job.
The Yull Object
The console program is simpler than the GUI program.
It has only three classes: the Yull class, the Andromeda class (encryption), and the Parameters class. The GUI app has many more classes, mainly to handle the graphical elements. Also, the GUI program handles the file selection and file name selection, passing the Yull object one input file and one output file at a time.
In the console app, the Yull object does all this work itself, determining the current file to be processed whether it exists or not, etc. After file handling, both the graphic program and console program are the same.
The Yull object continues with the setup. It validates again that the parameters make sense, that the source file exists and can be opened, that an output file can be created in the specified location, and also if a key was selected. If no key is selected, Yull will exit with a message. But if Yull was instructed to make a key, it will create a key of the specified length, with a minimum length of 100 bytes. The user can select nearly any file as a key - there is no limit to the size or location as long as it is a local file (that is, one that Yull can open).
Next, Yull figures out the read buffer size. This is one of the five parameters Yull uses to encrypt.
There are several "buff" size and "round" size controls. These control how big of a read buffer Yull will create, hence how many reads. The "rounds" value helps determine how many rounds per read, that is, the number of times a read buffer is submitted to encryption. The buffer size and rounds cannot be determinedly set by the user. The values are suggestions, which Yull uses, in conjunction with the level and key to create the actual values.
The dummy size option is just that: the amount of dummy data added to each read. This means that along with the original file data, random data values are also added to the input.
The final parameter is "personal data." This is a maximum 200 byte series of characters, like a password, which Yull uses to encrypt the key.
Once Yull has the read buffer size, it determines how many reads there will be from the file size by dividing one into the other. If the read size is 100 and the file size is 1000 there will be ten reads. If the read size is 100 and the file size is 1001 there will be 11 reads.
After the number of reads is calculated (which includes the buff size), Yull creates an array of rounds. A round is a call to the encryption class, Andromeda, to begin the encryption process. When Yull knows how many rounds and how many reads, it will create an array of keys based on the supplied (or created) key. There is one key used per each round of encryption. If there are 100 reads and 100 rounds per read, there will be 10,000 keys created. In the encryption process, if the key is smaller than the read buffer, it is extended to the size of the read buffer; if larger, truncated to the read buffer size. The keys are always the size of the read buffer - in essence a one-time pad.
Levels
There are six predefined levels: MAX, FAST, NORMAL, NEURO, TINY, and PLANK.
When you select a level, the values on the options tab change to reflect that level. You can, of course, override them easily.
Yull Setting Up Actions
The Yull class performs two other major actions, one before the encryption process starts and one during the encryption process. Based on the number of reads, Yull creates an array that number long and assigns a unique number to each element of that array with the aid of the "read order" option. The numbers are not sequential and have no relation to each other; they have no significance except that they are random and not close to each other in size. Yull then reorders that array to determine the read order for encryption. The read order is under partial control of the user by setting the "read order" value.
So, now ordered by value, the buffer numbers are: 7, 2, 8, 6, 5, 4, 1, 3
Which is the read order. Note again, these values are derived from simple math and the key. They are otherwise irrelevant, except that they are all unique. This means that Yull reads the seventh block of data first, processes it and writes it out, then the second, then the eighth, then the sixth, and so forth.
Dummy Data
Before Yull submits a block of data to the encryption object, it adds in random values from a call to the .NET RNGCryptoServiceProvider, which is also what Yull uses to create the key, if asked to do so.
The amount of dummy data to be added is either set by the user or by Yull within the range of 20 to 100 bytes. If you were to encrypt the file again, the random data would be different. Of course the random data inserted into the blocks is always different.
After Yull finishes encrypting the file, it zeroes out all of the buffers (arrays) it used, then deletes them, closes the open files and exits, returning to the UI object, which then updates the main UI form, writes some data out, and continues with the next file if there is one. The process for decryption is similar.
Yull is available for download and analysis at: www.yullencryption.com