Combary, how to develop in a nested list

This is how to produce a Combary based Encryption routine from top to bottom.

• Needed Assets

  • To create the encryption and decryption routines you will need the following:

    • HEADER INFORMATION

      • Tracking when we add bits for balance.

        • Periodically through the processes we will be adding bits to strings of data not long enough to complete a process. These will be noted in their sections, tracking is essential.

        • Other portions allow for them to manually change settings, such as the number of repetitions, for now the header will record this but in the future it will not (note the code appropriately that this is for the testing group to remember how many they selected)
          

      • File Type when created?

        • For simplicity we will be including if the file was binary, ASCII, or Unicode when it was uploaded. Later this will allow us to restore the file to the original type when we have finished decrypting.

        • We will eventually be restoring the file back to the original form with this software.

    • A combinations replacement system and a Huffman replacement system.

      • Combinations

        • Combinations is remarkably easy, you can use standard binary tables and just ignore any 1's and use the results with the appropriate number of 0's. We will need a simple algorithm by you to take the length (n) and the number of combinations (r) and make a value based out of that. There are many applications doing that online.
          

        • There are already programs online that do this in a wide variety of languages, some are open source, if we use open source for the test version we must note it ans then we must be ready to replace it in a later version.

      • Huffman

        • This references Huffman Encoding which you can find resources for online. It is an extensively known algorithm for converting possible variations to a different binary result. For example 6 possible outcomes can be 000, 001, 010, 011, 110, 111, and 10. This allows for more efficient storing of a lower variables of outcomes than using a higher binary value system.

        • The Huffman Encoding system is used in a wide variety of applications, it should not be difficult, if needed, to find a copy of an open source Huffman Encoding software.

      A compare files system

      • Original versus decrypted

        • We will have our original file and our decrypted file, we need (both to verify the software works ourselves and for the testing data scientists) to be able to verify the files match for contents.

        • Verifying a gigabyte to gigabyte might take a while, there are methods involving checking a hash value of portions of the file and other such out there, if there is a reasonable free option including open source then feel free to incorporate it.

      • This can be a separate software

        • If you find a software out there that does this already then let us just link out to it.

        • After all we do not need to get very complex in ours if possible.

• The input screen should be made up of two primary portions, the Key and the Data that will be encrypted

• Key Section

  • The key can either be randomly generated, uploaded in a text file, or be typed in by hand. Minimum and maximum size elements exist. Those are 32 bits to 128 bits.

  • Text File Upload

    • Detect if Binary, Unicode or ASCII

      • If ASCII or Unicode then convert to Binary, check if bit count meets minimum/maxmum requirements. If yes then proceed to next major step.

      • If Binary then leave as Binary, check if bit count meets minimum/maxmum requirements. If yes then proceed to next major step.

  • Text File Random Generation

    • Create a key size selector, minimum of 32 bits and maximum of 128 bits.

      • Create a "Save Key" function that will save the key to a separate file entirely.

      • Allow the random button to be hit as many times as they desire

  • Manual Key Input

    • Detect if pure binary or ANSCII

      • If only 0's and 1's then treat as binary.

      • If any characters other than 0 and 1 then treat as ANSCII and convert, display converted outcome on screen in a separate box below their input.

    • Detect length and prevent continuing (and warn) if size is too small or too large (in bits).

• Data to be encrypted section

  • This is to be called, internally by us, the DATA FILE. The DATA File is actually going to be a series of such files as we go through the processes listed. The idea is original data gets changed to new_data_1, new_data_1 gets changed to new_data_2, new_data_2 gets changed to new_data_3, new_data_3 gets changed to new_data_4 and so forth.

    Upload option

    • If Input is Binary already then keep as binary (text file only)

    • If Input is ASCII/Unicode then convert to Binary (text file only)

  • Input method

    • If they have a file already made.

      • Convert text file to binary from ASCII or Unicode if needed.

      • If text file is already binary proceed to next major step.

    • If they need a file generated.

      • Create two files for them, one to compare with later and one to act as our source for encrypting then decrypting.

      • File should be made in binary

• Minimum/Maximum Values

  • When they are inputing data we need to have a certain specific minimum and maximum size and we need to make them aware of it.

    Minimum/Maximum DATA FILE Size

    • The minimum file size is 2048 bits

    • For this BETA Software the maximum file size is 1 gigabyte (800,000,000,000 bits)

    Minimum/Maximum KEY size

    • The minimum key size is: 32 bits

    • The maximum key size is: 128 bits

• To Salt or not to Salt?

  • The testers will want to test in both environments in my opinoon, therefore we need to provide them the option to not add salts to the processes.

    For all processes?

    • This is test software so we shall make it an option to only salt a specific processes with your best look for making this work on the input screen

    • We need a way to tie this into doing solo processes as well

    Alter the save file

    • We need obviously to make it so that we alter the name of the save file in some manner when we do this.

    • I propose Salts abcd type notation, where they input thier name (for this example we will say TEST1) we will append what was done like this: TEST1-Salts-ab (then add any more we need to the name)

    • This should satisfy them on a naming conventions for the testing period.

• To do a solo process?

  • I have considered it long and I need to allow testers to test a process alone.

    Please provide an option to only do 1 process of their choice. This will also benefit us in finding and smashing any bugs.

    • This goes for encrypting...

    • And it goes for decrypting...

    Allow them to decrypt a file at choice also

    • They may have saved an encrypted file, or sent one to someone else, and are seeking review of what they found.

    • Our goal is after all to seek peer review above and beyond anything else.

• The combinations are done first

  • The key determines the size of the combination.

    • We examine the key, taking 3 bits at a time per each combination needed. See "Further uses of COMBINATION MAIN PROCESS" for more details.

      • For example 010101110001010101011 would be divided up as 010|101|110|001|010|101|011

      • The first combination would use 010, the next would use 101, and so forth. This determines the LENGTH of the Combination.

    • We also need to determine the content of the Combination, this is done using the DATA.

      • The Data will be examined to create a point count equal to the length of the combination. For example an 8 length combination has 256 possible outcomes, those count as points in my language.

      • The data generates the infil of combinations and then we proceed to add standard Binary from the DATA to fill the holes.

      • For example xyxyxxyy could represent our combinations, where y is the combination. We take from 101010011110010 and fill in the x locations then. 1y0y10yy would be the result.

      • There are salts that can change that but we will be discussing those a little further down.

      • Complete a combination length with data in both the combination and the binary before moving on to the next one.

  • If there is not enough bits for the process yet we have bits left over or if the key runs out...

    • Determine if it is in the Combination stage or it if it is in the add binary stage of the process.

      • If in the combination stage you will need to add bits for both completing the combination and in completing the binary, note in the header as appropriate.

      • It may only require bits in the binary phase, note in header as appropriate. In both cases this will be APPENDED TO THE END OF THE DATA.

    • If the key runs out

      • Check for salt or extra requirements

      • and/or append a copy of the key to the end of the key (or as modified as needed)

• Binary is added next

  • As stated Binary is added after using creating a combination

    • This provides another chance for Salts to be applied

      • Alternatively we could use a different encryption (AES for example) on the pure binary

      • Salts I propose will be listed in a separate section below.

  • Binary is 'normally' appended left to right..

    • Possible non-salt variations include:

      • First combination has binary appended left to right, second has it appended right to left.

      • It is possible to take data from the rear of our DATA FILE and append it in reverse to the current area being used (and remove the used binary as we go). However this would require us to form all combinations and count the remaining bits as we go to make sure we append to the end as needed FIRST before using this method (not being used in this version but here for example)

      • It is also possible to use a reversible hash of the binary or another encryption system entirely upon the standard binary.

      • The only firm rule is we do not write over the positions of combinations and we make it so we can for sure recover the data appropriately.

    • We can salt the combinations and the Binary

      • The Combination for example can be changed as to what stands for the combination, a 0, a 1, or a 2. The binary then has to have values changed (see the Salt section below for Combinations for full list)

      • The binary can be salted as well in a variety of ways including just changing the numerical value by altering it with a section of the key.(see the Salt section below for Combinations for full list)

• The Key

  • We will be using the key differently for each MAIN PROCESS as well as the First Process.

  • In this case we will be reading the key from left to right for the Combination Process

  • If the key ever runs out we append a copy of the key to the key (adjusted for Salts)

  • The Key should be used a lot in this manner and this is an expected usage of the key

  • This means if an intruder guesses 69 bits in the key and there is 70 bits in the key he will be doing a lot of processor time and not getting anywhere because as the key goes on it changes.

  • There is one potential issue with the key here and elsewhere. That potential issue, against the odds, happened in a trial explanation of the system. So a solution is needed. That solution and issue is as follows: The Key was x length and the salts, the combinations, the whole of it ended up using exactly the size of the key. This meant the next cycle and the cycle after that also used exactly the size of the key (and it would have repeated ad-infinity). To solve that, since we have an easy to decipher key, is that if it falls exactly on a similar length of the key (if abcdefghijklmnop was our key this can also include efghijklmnopabcd) in repetition for three times then the fourt repetition of the key is deliberately cut of the first bit and that bit is appended to the back. This should handle any such issues unless the key is 111111111 or 0000000 type nonsensical junk. As such you will need to also detect key input and make sure it does not have all 1's or all 0's. This goes for all processes.

• Further uses of COMBINATION MAIN PROCESS

  • This is where I need to talk about the random variation

  and somehow I forgot where I was going with this, damn COVID-19....

  • If I remember I want this spot reserved properly.

  • I hope I can remember because I really wanted it in here.

• This is a very small and simple process, on its own it would only qualify as an NP-Easy formula in my opinion. The purpose of this Process is not to be a end all be all on its own but to add an additional item to our Sorting Process specifically to help make the other two routines far more effective via that sorting process increase. Note this routine can be swapped out for any other low level encryption routine and that is also a selling point. If a bank wishes to have a secret encoding method here that is different then this is where they could do it without impacting the capabilities of the encryption routine but instead that would increase the difficulty for anyone who knows the version we are making here today.

• The basics

  • The mechanics

    • Binary Number Replacements

      • This is a simple swap system where we will be replacing code snippets using a Huffman with like sized snippets.

      • Literally we will be swapping, based upon key, things like 0000 to 0101 and 111 to 111 or 000. The key determines the swaps as per the section 'using the key'.

    • Huffman based swaps

      • To do Huffmans we need to follow the rule of "Smallest one(s) first. This works for encryption and decryption both and is essential in the creation of swaps in this system to work without flaw.

      • In the key section I shall provide an organization table for different Huffman routines and the number of bits involved.

  • Notation

    • Noting the project

      • In the coding section about the Shuffle I wish you to include the following line of text:

      • The encryption routine at this location uses what is called "The Shuffle". The Shuffle however only has value as a third entity to the Main Processes to help our Sorting Process have more variables. In of fact for those companies worried about future advances in processing power they can use their own encryption routine here instead of this weak process.

    • In a "About Document"

      • In a word document or something we need to include a disclaimer about this specific section. It is vitally important to let the testers known about this section and some of the 'quirks' it has.

      • You see it could be possible that this process can grow or shrink the file due to the use of the Huffman if the data presented is not sufficiently random. A document with a high skew that has this one go first (or possibly second) or where the document somehow accidentally as part of the encryption becomes unbalanced in the ratio of 1's to 0's can grow as much as 10% (usual maximum, more can happen) or shrink by a small percent when those skews happen. Even when there is no skew it is likely to see a miniscule but noticeable change in the size of the file after it passes this stage.

• Using the key

  • Key Expansion

    • The key is simply not long enough in reality for this Process therefore we will need a way to expand it and make it somewhat more complex than originally designed.

    • To this end we will be using a simple system to dramatically grow the key as needed to meet the needs

    • The key, as originally started, is key 1. To this key we will append all other modified versions of the groups and call the added keys "Master Key".

    • This is because we will be modifying Key 1 + additional keys to generate the next iteration.

    • For example Key #2 is derived by taking the "Master Key" (which currently only holds Key #1) and by starting with the left most bit uses the the 2nd bit after each. Thus if our bits are ABCDEFGHIJKLMNOPQRSTUVWXYZ then we will be first taking ACEGIKMPRYVXZ and then adding BDFHKMOQSUWY so we have ACEGIKMPRYVXZBDFHKMOQSUWY as key #2. This is appended to the back of the MASTER KEY to form the new master key.

    • If Key #3 is needed (yes it will be) then we use every 3rd value in MASTER KEY. The same sort of function for #4, every 4th, for #5, every 5th, and so forth. Each new addition is added to master key as it goes along.

    • This will grow very fast and will not be to very extreme ends. For example a 40 bit key would start at 40, grow to 80, grow to 160, grow to 320, grow to 640, grow to 1280, and so forth on a doubling scale. More so as we remove possible swaps we remove variables we no longer need.

    • The key can be expanded as large as needed to complete the work and no there is no real complications to using this.

    • We do NOT wrap when we do this, for example if there is only 5 bits after the last one we used and we are doing every 7th or something like that we do not go back to the start we just end the current set and start on the next set.

    • Example: 0011 0011 0011 0011

    • If we are looking for every 7th bit in this we we get the first 0, then a 1 then then another 1. We start fresh even though a 1 is hanging at the end

    • Color coding it looks like this (forgive the brackets, they help make it stand out):

      (0)[0]|1|(1) [0]0{1}(1) [0]|0|(1)[1] 0{0}(1)[1]

  • Determining Swaps

    • After much consideration I have decided to make it smaller rather than larger, this one operation has two sides, either the file size can change somewhat past one percent or the temp files needed to keep up might swell to vicious size and require a lot of processor time to complete. As this process is barely needed we will go small. The size change actually does help expand the possible variations significantly in its own way so that is less of a problem than it would seem.

    • Draw four bits from the key, starting with the first, the third, the fifth and then use the seventh. Do a bin2dec (Binary to Decimal) conversion.

    • If the result is a 0: Then we will have four triggers at four bits each.

    • If the result is a 1: Then we will have three triggers at four bits and one trigger at three bits.

    • If the result is a 2: Then we will have two triggers at four bits and two triggers at three bits.

    • If the result is a 3: Then we will have two triggers at four bits, one trigger at three bits and one trigger at two bits.

    • If the result is a 4: Then we will have two triggers at four bits and one trigger at two bits.

    • If the result is a 5: Then we will have one trigger at four bits and three triggers at three bits.

    • If the result is a 6: Then we will have one trigger at four bits, two triggers at three bits and one trigger at two bits.

    • If the result is a 7: Then we will have one trigger at four bits, one trigger at three bits, and one trigger at two bits.

    • If the result is a 8: Then we will have one trigger at four bits and one trigger at two bits.

    • If the result is a 9: Then we will have three triggers at three bits.

    • If the result is a 10: Then we will have two triggers at three bits and one trigger at two bits.

    • If the result is a 11: Then we will have on trigger at one bit.

    • If the result is a 12: Then we will have one trigger at two bits.

    • If the result is a 13: Then we will have one trigger at three bits.

    • If the result is a 14: Then we will have two triggers at three bits.

    • To determine substring length we will be using a system based upon four bits and use bin2dec to get the following results. We use the four bits after the first seven bits (since we sorta used them)

    • If 0 then substring length is 24 bits.

    • If 1 then substring length is 36 bits.

    • if 2 or 3 then substring length is 48 bits.

    • if 4 or 5 then substring length is 72 bits.

    • if 6 or 7 then substring length is 96 bits.

    • if 8 or 9 then substring length is 120 bits.

    • if 10 or 11 then substring length 168 is bits.

    • if 12 or 13 then substring length is 192 bits.

    • if 14 or 15 then substring length is 240 bits.

    • The next step is determining what is the actual trigger value. We start with the SMALLEST SIZE(S).

    • Discard the first 7 bits (where we determined the triggers) and the next 4 bits (where we etermined the substring length) first. Continuing after that set of bits we use the smallest size and find a number of bits equal to the smallest size in the key (1 key bit for 1 trigger size, 2 key bits for two bits of trigger size, and so forth).

    • Next we determine the next smallest trigger. If this one conflicts with the existing trigger we then look at the next number of bits to get the trigger. If by chance that matches continue seeking a different trigger from the key until the key + a copy of the key is run out. If this happens then follow this guideline: If this trigger is the same size as the other then change the last bit's value. If the key is larger then change the first bits value. If this does not work then change all the bits values. Finally if it still does not work then remove this trigger (when we have multiple triggers this can happen, for example result 6 from our trigger guide has four triggers possible. We could have 00 for the first, then if 000 was the result for the 3 bit version we would end up with 100. If our two four bits were each 0000 then 0001 would not work and 1000 would not work and 1001 would also not work. Ergo both of the 4 bit triggers would disappear in this scenario. However the odds of that happening are extremely remote so this is unlikely to happen in reality.

    • Now we should know all of the triggers exact values and the substring length and can proceed with our process.

Salts?

• Yes we can Salt but no we wont

  • Please see the Salt subsection for more details

  • Salts can be applied at the key, in the substitutions, and otherwise but currently we do not plan to implement them.

• Decrypting this is a series of steps, do not advance a step until the previous one is fully finished

• The basics

  • One Iteration at a time.

    • How to do an Iteration

      • We start with the first iteration. We know how many bit should follow each trigger (yes we re-create the triggers) so we find every one of the first iterations. Create a temp file with them all separated from the remaining code.

      • We then go to the back and read backwards the second iterations, keeping track of how many bits should follow each we find until the remaining bits in iterations 3 and up match what we expect.

      • Start from the left for iteration 3 and repeat the process.

      • The primary rule here is to make sure our count of what the remaining bits are after each one is counted in a given iterations are indeed more than our possible amount before conducting another pull of the current iteration. For example if we know there is 10,000 bits left and we have only got enough items in iteration one to account for 8,000 of them we can continue pulling.

      • A quick example, our trigger will be 1 and substring size will be 3

      • 100001010101110111 converts via encryption into (follow these steps:)

      • Divided into substrings it is:

      • 100|001|010|101|110|111

      • The first iteration will have 1 | 001 | 01 | 1 | 1 | 1

      • The second iteration will have 00 | - | 0 | 01 | 1 | 1

      • The third iteration will be: - | - | - | - | 0 | 1

      • Therefore following the encryption rules we would have 100101111 for first iteration, second iteration would be 0000111, and third would be 01. We place first iteration in proper order, 100101111 and reverse the second iteration 1110000 and then place it in the back waiting for the rest to infill. There is only the third iteration left and it goes immediately after the first as 01. Our new line is 100101111 01 1110000

      • Now to learn to decrypt it

      • 100101111011110000

      • We learn this by, again, doing the first iteration and counting how many are left at each step. We know (in this saltless example) there should be 18 bits and that this means 6 iterations are likely (remember that salts can adjust this, see the salt section below) because we can have Huffman type triggers as well.

      • STEP 1:Thus we checked the first bit, it is a 1, that is a trigger. Iteration one got a 1 added and we determined two bits follow in future iterations. There is now 17 bits remaining and 2 are in deeper iterations. (00101111011110000)

      • STEP 2:We then check the next bit in front and it is a 0, not a trigger, and the next is a 0, 0 and '00' are not triggers, we then check and find a 1, looking we see 0, 00 and 001 are not triggers but 1 is a trigger. However this is the end of the substring so all three are added to the first iteration temp file. Our first iteration file now hold 1001 and we know two bits are in lower iterations and we have 14 bits remaining to check (01111011110000)

      • STEP 3:Our next check starts with a 0, then a 1. The one indicates a trigger and that the next bit is going to be in deeper iterations. Our first iteration temp file now has 111011110000 and we have three bits expected and 12 bits remaining. (111011110000)

      • STEP 4:Next we check and find 1 up front, first iteration temp file is now 1001011 and we have five bits expected and 11 bits remaining. (11011110000)

      • STEP 5:Next we check and find 1, first temp file is 10010111 and we have seven bits expected with 10 bits remining. (1011110000)

      • STEP 6:our sixth check comes up with a 1, our temp file number one is now 100101111, we expect nine bits remaining and there is 9 bits remaing. THIS IS OUR FLIP MOMENT! Remaining is 011110000

      • STEP 7:reading from the back requires we know the first iterations 'leftover' per. For example STEP 1 had two remaining bits. So we look for two bits and get 00. No triggers means this is 00 in the second iteration (0111100)[00]

      • STEP 8: There was no trigger activated for step 2 therefore we do not look for any bits in this step but move on.(0111100)

      • STEP 9: there was a trigger for step 3 and one bit remained, therefore we need the next bit from the back which is a 0 (011110)[000]

      • Our binary string has been reduced to 011110

      • STEP 10: we look and find that step 4 had two bits, reading from the back we get a 0 then a 1. The one would be a trigger except it is at the end of the substring. Our second iteration file now has, still in reverse order, 10000 (0111)[10000]

      • STEP 11: we look and see that step 5 had two bits in later iterations and when we check the remaining string of 0111 we see a 1. This indicates a trigger and thus we expect a bit in the third iteration. Our temp file, still reading backwards, is now 110000 (011)[110000]

      • STEP 12: We look at step 6 and see that it had a trigger leaving two bits remaining, we check and find a 1 (from 011) indicating a bit in the third iteration. Our second iteration string now looks like 1110000 (01)[1110000]

      • STEP 13: We have two bits remaining, from step's 11 and 12. In proper order they are 0 and 1.

      • STEP 14: Undo the reverse of temp file iteration two into 0000111.

      • STEP 15: Append iteration 1, 2, and 3 in proper order to get 100101111 0000111 01

      • Now to place them

      • 100101111 0000111 01 and I will use () to show already removed and placed and {} to show the current step removed.

      • just keep doing the iteration undoing... 1 means two next which was 00, that is our first substring.

      • {1}00101111 {00}00111 01 therefore would be our first substring in visual

      • (1){001}01111 (00)00111 01 now gets 001 for the second substring [100,001]

      • (1)(001){01}111 (00){0}0111 01 now gets 01 and 0 for the third substring [100,001,010]

      • (1)(001)(01){1}11 (00)(0){01}11 01 now gets 001 for the fourth substring [100,001,010,101]

      • (1)(001)(01)(1){1}1 (00)(0)(01){1}1 {0}1 now gets 101 for the fifth substring [100,001,010,101,110]

      • (1)(001)(01)(1)(1){1} (00)(0)(01)(1){1} (0){1} now gets 110 for the sixth substring [100,001,010,101,110,111]

      • We went from:

      • 100001010101110111

      • To this with encryption to decryption:

      • 100001010101110111

• Why Salt? What Advantages?

  • That said we can use salts as follows:

    • Altering the key per 'cycle' of the MAIN PROCESSES

      • This would mean a different hash per each 'cycle'. The only purpose here is to obfusicate the sorting process even more.

      • This could be done by examinging one bit and triggering if a 1 per a process cycle.

    • Possible salts not included

      • A possible salt I considered was allowing for less or more MAIN PROCESSES (if they are abc I could allow aabc or cb type results). This is not needed in the current testing model but is an option.

      • Another salt I considered was one that switches the Shuffle Process with another encryption routine entirely, this would necessitate additional coding I do not currently see a need for but exists as a future option.

  • Reasons to Salt:

    • Salting can help increase difficulty in the first process ever to be worked.

    • Low cost to the salting here since the process is only done once.

  • In the future

    • In the future this will probably lead to addition of another MAIN PROCESS or in an alternate for The Shuffle.

    • We could also change the way we hash, change some salts, add some salts, or otherwise tinker in here.

• I decided to not use salts in the Shuffle, this should save some time.

  • Why?

    • We have enough complexity as it stands.

    • Also I have never, ever, ever, been truly happy with the Shuffle routine.

• Possible Salts:

  • Easy

    • We would need to create SUBLENGTHS like in the Juggle but we could then change the substitutions inside each sublength

    • I figured this could get processor time heavy and decided to nix it entirely.

  • Hard

    • This one would require Huffman to do different sizes to different sizes (like making a 5 bit outcome into a 3 bit one and visa versa) and would inflate the files rather hard and fast if bad luck happened.

    • Not being used

• When we are done we save a "Finished" version of the DATA File

  • Allows comparison of the original and the newly decrypted file.

• Revert the file to original

  • This would mean we would need a header section to identify that this was done.

  • Added to the Header File area.

• This is based upon Patent and Patent Pending materials, all rights reserved.

• Specific Patents issued:

  • US9786318B2, US10121510B2, and US9437236B2

  • There is also multiple Pending Patents in the United States

• Contact Information regarding Patent inquiries:

  • My email is Michaelhh@gmail.com and please include something about the Patents in your title.

  • The law firm handling my Patent Filings is: Nolte Lackenbach Siegel

• First to prove Combary works

  • Combary is a revolution in the area of Binary and Ternary. Combary

    • Historical

      • The first effort to use binary to store data is commonly attributed to Gottfried Leibniz but it was Thomas Hariot who in fact used a Binary to Decimal system and discovered how binary could store numbers

      • Therefore in context, as Binary and Ternary were created around 1646-1716 by Thomas Hariot, Combary is the first actual advance in this numbering field in over 400 years.

    • Capabilities

      • Combary represents an easy way to use Ternary but output Binary (or visa versa) without issues. It can help Quantum Computing to have far less issues than currently exists.

      • Combary also allows for two different methods to be used to store or transmit data. Since it is two languages it allows for things such as magnetics and the absence of magnetics to store data.

  • Michael Harrington's specific claims about Combary

    • Performance

      • When comparing AES to this Combary Encryption system Michael Harrington claims the following:

      • A) The Combination Process has more capabilities than AES when tied in with salts and additional encryption routines.

      • B) The Juggle Process is amongst, if not, the hardest possible systems for a brute force attack.

      • C) The use of these three routines in a demi-random manner increases the difficulty of an attack beyond that the strongest yet used AES.

      • D) That knowing all but one bit, so long as that one bit's specific location is not known, should still cost too much processor time to identify the mistaken bit.

      • E) The variable key length is far more secure with this Combary Encryption System than the fixed length keys of AES.

      • F) That this shows the value of quasi random data if done correctly, in increasing the difficulty for a hacker.

      • G) That to achieve the optimum encryption level that fewer cycles, and a prediction of less processing power needed, exists.

      • H) That changing the size does not give advantages but instead increases the total dimensions of possible outcomes to heights greater than 2^(Original Data file size) could ever do but instead is now (2^(Original Data file size * percentage increase in file size)) +1 bit (rounded up).

      • I) That Combary is the first advance in the concepts of using Binary, Ternary, and higher to store data and it is one of, now, three lowest possible sized languages to store data.

      • J) That Combary allows for two distinct data types to run at the same time or it can be two portions of the same data.

      • K) That in the physical realm the use of two data types that can be read/written differently can mean different methods to store/transmit ternary on a normally Binary type source technology.

    • Processor time and size distortions

      • My prediction is that the processor time will be lower, the way AES works is most bits get a movement per function and there are a number of functions and there is a number of repeat runnings of AES to achieve optimal encryption. While this Combary Encryption System uses the key far more dynamically (and that does add to the processor time) the total number of manipulations a given bit has is approximately 1/10th (rough estimate while sick with COVID) that of AES. Therefore it is my opinion that this should render my system as far more power efficient than AES.

      • There is a bit of size increases. In some iterations I examined doing in the past this could be 300% at the highest. The current iteration should keep total size growth under 2% more than 50% of the time.

• To provide a proof of concept for investors, industry experts, and others deep in the field:

  • This is going to be an proprietary software license for TESTING software. This is not for commercial or personal usage.

    • The proprietary software license

      • We need to incorporate the license into the software as part of the process but one that only comes up once would be preferable.

      • Irregardless the license is legally required or they may try something if truly greedy and evil.

• This is going to be an proprietary software license for TESTING software. This is not for commercial or personal usage.

  • • We need to incorporate the license into the software as part of the process but one that only comes up once would be preferable.

    • Irregardless the license is legally required or they may try something if truly greedy and evil.

This is the creation of Michael Harrington owner of Permanent Hard Drive LLC, materials in here include copyrighted materials and Patent and Patent Pending materials, all rights reserved! Feb 12th 2021