This is a method of combining inline generators of any sort
(in the code below I use LFSR skipstate generators) in a way which increases
the complexity of the system.

The idea is to use eight inline generators to select a byte from a
key-dependent permutation of bytes. The output is used as the input to
the generators in the next round, and a 8-bit wraparound counter is also
xor'd with the output of the generators before entering the p-box.

Because the 8-bit counter ensures that the output from the generators
can select any byte, even if it remains constant, the generators can
have rather weak random properties without severely compromising the
device's effectiveness (ie, sending it into a short cycle). Clocked
LFSR's probably would not be too devastating.

Of course, it makes more sense to use proper generators. In the
implementation below I've used LFSR skipstate generators; anything else with
good random properties is candidate, and the generators do not have
to all be the same type (combining types, in fact, is a very sound idea).

The code below initializes the p-box in the same manner as RC4, and
initializes the generators as in Tom7-fselect.

Analysis

Using my program stat, this produces
well-distributed pseudo random bits for a variety of keys (up to degree
7). This is by no means a thorough test, but it performs as expected,
at least.

The biggest weakness I see in this is that the P-Box does not change.
This seems to make a known-plaintext pretty reasonable.

Improvements

The P-Box does not change. I tried to think of an elegant way to make
it change without totally ripping off RC4, but failed. It would greatly
increase security to have the P-Box change. Since the P-Box must change
by the key in this implementation anyway, this should not make hardware
implementations much more difficult or expensive.

The code below uses generators with periods which are not all
relatively prime. I highly recommend using generators which are; my source
of data Applied Cryptography did not have enough.

LFSRs are considered insecure and probably should not be used.

Implementation

This implementation just spits out the bits in ascii notation as my
other programs do, something like: