🚀 go-pugleaf

Following is the heart of the program (though not necessarily
the most important part).  If you assume that the three key 
arrays are full of unpredictable PRNs and that the seed is an
unpredictable PRN, and that zipkeys fills up the three arrays
with more unpredictable PRNs, what is the weakness of this 
algorithm?

Note:
  KLEN1 = 1013
  KLEN2 = 1019
  KLEN3 = 1021
  PRIME(X) = the (X % 613)th of a list of 613 prime numbers
             (which are stored in a pseudo-random order).

Also note:  The PRN generator is salted with nine bytes of
            data (4 from keystroke latency, 2 from time of
            day, 2 from process id, and 1 from the cleartext).
            These are all jumbled together (so that each of
            the nine salts is partially a function of each of
            the rest), and then stored, encrypted (of course),
            as the first nine bytes of cipher text.

The idea is to generate ~3K bytes of computationally expensive
PRNs, and milk ~1M byte of cheap-but-unpredictable key stream.
Is there a reason why this won't work?

----------------------- clip clip ---------------------
void scramble(seed)
uint seed;
{
    rint   inc;
    ruint  outc;
    ruint  i1=(PRIME(seed)*PRIME(KLEN2))%KLEN1;    /* index into key1 */
    ruint  i2=(PRIME(seed+i1)*PRIME(KLEN3))%KLEN2; /* index into key2 */
    ruint  i3=(PRIME(seed+i2)*PRIME(KLEN1))%KLEN3; /* index into key3 */
    ruint  prev_feedback = seed;
    ruint  feedback;

    while ((inc=fgetc(inf)) != EOF)
    {
        feedback = prev_feedback;

        outc = (inc ^ key1[i1++] ^ key2[i2++] ^ key3[i3]);

        i3 = (i1+12+i3+feedback) % KLEN3;
        if (i1 >= KLEN1) i1=0;
        if (i2 >= KLEN2) i2=0;

        if (!i1 && !i2)
        {
            zipkeys(feedback);
        }

        prev_feedback = ((ENCRYPT) ? outc : inc);

        fputc(outc, outf);
    }
}

----------------------- clip clip ---------------------

-- 
Peter K. Boucher
--
RIPEM public key available upon request.