|
This White Paper (parts 1 and 2) is a general discussion of how Yull works with code examples.
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, along with others, like Blowfish, 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 the 8 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. This document (Parts 1 and 2) discusses how Yull works, with code examples. 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.
his key space, which is used in most other encryption programs, is not very large; and even if today (2015) it is relatively immune to a brute force attack,
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 4 and 20. According to the Wikipedia page for AES, it's 10 cycles for a 128 bit key, 12 for 192 and 14 for 256 bit keys. Yull uses a variable number of rounds ranging from 1 to 150.
Other encryption programs, mainly those which rely on AES, add a fixed amount of dummy data (this is part of AES does), 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% 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 min and max size of the read buffer used
- the level of encryption
- the min and max number of rounds in the array of rounds
- amount of dummy data added
- order the reads are made
- 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 1 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 149100 (or 2.082701e+217, which is 2.08 times 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 2 possible read orders (2! or 2 factorial, which 2 x 1). If there were 10 reads, there would be 10! (3,628,800) possible read orders (10x9x8x7x6x5x4x3x2x1) and if there were 50 reads, there would be 50! or
30414093000000000000000000000000000000000000000000000000000000000
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). See Part 2 of the White Paper for details about this.
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 the numbers that fit, between 20 and 600. If your file was, say 10K in size (10,240 bytes), you would have to try all 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 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, GPU arrays one uses.
Dummy Data
Yull will always add dummy data to the read buffer. Yull will prepend between 20-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. While this can be stored in the options file (see the Guide on the web site), and the options file can be encrypted, 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 the normal ASCII characters (including the space) along with most of the 128 values above 127. You would enter those via your numeric key pad ALT+ two or three digit value:
This is Ascii 11, 147, 178 inputted via ALT+11, etc. This gives you 247 possible characters values and with 200 characters for the Personal Data you have something like 247200 or 3.4625x10478 which like most of my other numbers is way too big to imagine. More than all 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 SHA512 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. Blocks 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 1.152921504606846976 x 1078 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:
7775892182227363846365224303373866345909602604749974979305519536708851240595825119152763630559279561914
76258211968698749794062201796468994358639583677597277966221496081386040428524624036837389354858526340577092
56771299230380098822466080142001159030156662377138169091661053378027306159140588698401044531517806120574444
647452982608759967619192447037241981639101929668716184831900032478998027811609344055333647488533711459486991110
4052877511222356822422718874052733173760000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000
For 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, 3 seconds to encrypt (and decrypt) that is actually an additional safety feature in that brute force will take too long, more time then 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), is it 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 UI Object
There are two tabs: File and Options. This is the main screen: the File Tab.
This is the Options Tab:
You can see there are four menus and two tabs. The File tab has an Encrypt section, Decrypt section, several controls to display files and other information about them.
I've selected file 256 in M:\test\source folder. Yull is instructed to ask for the key file:
After pressing "Encrypt":
And then ask for your Personal Data (because the Ask for PData check box is checked):
A bit corny but whatever. After pressing OK:
And file 256 is encrypted.
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.
As you can see from the values in the Options Tab image, 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 max 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 10 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, PLANK.
When you select a level, the values on the Options Tab change to reflect that level. You can of course override them easily.
Default Max Level Values
Default Plank Level Values
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.
Here's part of the file pictured in Figure 4:
In this case each read is 96 bytes long (0x60), and these are the first eight reads.
When Yull is determining the read order, it might get values like this:
Buffer No. Value
1 390
2 107
3 414
4 242
5 192
6 171
7 83
8 169
So now ordered by Value the Buffer No.s 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 7th block of data first, process it and write it out, then the 2nd, then the 8th, then the 6th and so forth. And written out in this order.
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.
So now the block to be encrypted might look like this, where Yull has added 64 bytes of dummy data at the start of the read buffer:
64 bytes of random dummy data prepended to a read buffer
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 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.
The White Paper continues with the White Paper Part 2)
| 