Encryption Thoughts #2

Continuing earlier thoughts, I have a pre/post encryption algorythmn, that completely changes the internal structure as it encrypts/decrypts; Using very unique and simple algorythmns. If it starts getting complicated it slows the algorythmn down, the number of pre/post peices alter in every step how it changes, so only by having the original key/RNG string could you duplicate it.

Earlier i commented on using prime numbers, I which i highly suggest in use of this process, since it can greatly cut down on the number required subkeys to be considered 'secure', and thereby increase encryption. 2,3,5,7,11,13, each increasing by 1 till it passes of it's max, it then turns around and starts at 1, or some other predetermined number (which could be random). which totals at 30,030 combinations, but i have seen primes in the hundreds; increasing complexity, even for 8bits of combinations very complex.

However, for the main key itself, primes are not applicable, or useful, since you might select the Alphabet only, or a combination, or all of them at random. Since the length is unique, it's internal counters and rythmns follow different rules, using odd numbers for even keys, and even for odd keys; And failure to follow the rules can remove anywhere from 1/4 to 1/2 of it's potential. The stepping rules are different as well, adding/subtracting any number.

There are further ways to greatly increase complexity and strength, however i have made limits under certain rules. Following these rules, i have tried to even out at high strength without high memory/CPU cost.

1) The bit sizes for the codes never exceed 12 bits, and never go under 8 bits.

Reasons: 8bits has much complexity, but not as much as i'd like. 12 is the inbetween number between 8/16, allowing for middle areas (3bytes for example) to increase greatly in key combinations and complexity. If Memory requirements increase too large, it will be difficult to implement in chips and devices. Memory used for keys is as follows.

8bit 4K per key, 6K for speedups
9bit 8K per key, 12K
10bit 16K per key, 24K
11bit 32K per key, 48K
12bit 64K per key, 96K

Using a 32bit key, straight up, in memory would require some 48Gigs, i consider it too long to create, work with, and not worth it in exchange for it's encryption abilities. (2^32 * 4 * 3) 2^32 * 4 for actual key combinations, and 2 or more for the keys, and 1 for pre/post encryption. With this in mind, i perfer to use several smaller keys to create the complexity without memory consumption requirements.

Era