Tom7fselect stream cipher
This is a method of combining generators of any sort (in the code below I use LFSRs) in a way which increases the complexity of the system. The basic idea is to use a multiplexor with k input generators and n selector generators to select between 2^{n} combining functions to combine the k bits. The output is the output of this function. For the functions given and used below, k must be odd. I've used 4 functions in my implementation and five input bits, so n=2 and k=5. The functions are threshold, xor, overflowsum, and inverse threshold. The initial state of the generators is determined by the key, and the generators are also clocked a certain number of times based on the key to initialize them. In the implementation below, I cycle through the 7 generators and fill each of their 4byte data from msb to lsb from the key (cyclically), and then use a fifth byte and clock the generator that many times. This implies a maximum key length of 5*7*8=280 bits; shorter keys are repeated to make the requisite 35 bytes. Each function must produce a bit with even distribution based on the k input bits. The functions used are:
The idea could certainly be expanded to more functions, and more generators. Analysis Using my program stat, this produces welldistributed 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. Breaking the generators sequentially could reasonably lead to breaking the cipher. Since there is no feedback mechanism, a generator which you have 'solved' always produces the same output. The output of any generator is heavily obscured by the others, but a probabilistic attack could work with a knownplaintext scenario (given that I know my solved generator output 1, and the entire device output a 0, what is the probability that generator x output a 1?, etc.) Since the initial state of a generator only depends on 5 bytes (= 40 bits) of the key, this especially facilitates an attack. Knowing n1 generators does not even mean you necessarily know the output of the final generator (when either threshold function is used, there are times when the output of a single generator does not matter (all the others have voted 1, for instance). It seems like a difficult attack to mount and I wouldn't know where to start, but it is a weakness nonetheless. Improvements 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. Some sort of feedback to the generators would be useful. It seems to make it inelegant, but a skipstatetype feedback from the output and between the generators would probably hinder cryptanalysis. LFSRs are considered insecure and should not be used. A key scheme in which each key bit affected each generator's state would be especially useful. I have used the method described above in the interest of simplicity, but do not recommend it. Implementation /* C Implementation of Tom7fselect stream cipher. This code is distributed under the GNU public license; see http://www.gnu.org/copyleft/gpl.html. I can't make any claims about the security of this algorithm because I am not a trained cryptographer, though it produces (as far as I can tell) statistically random output. This code should be thought about, but not used unless you know more about this than me. The biggest fault I see with this is that the generators are not all relatively prime in length  Applied Cryptography did not have enough given for me to pick 7 that were. The period is still something pretty huge, at least 2^127 bits before it repeats. Tom 7 http://tom7.org/ */ #include Back to Tom's Cryptography Thingie.
