Tom7-fselect 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 2n 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, overflow-sum, 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 4-byte 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 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. 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 known-plaintext 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 n-1 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 skipstate-type 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 Tom7-fselect 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.
|