> >IPG Sales wrote:
> >> Obviously, you meet our requirements for the release of the IPG ABC ...
> At 08:01 AM 3/19/96 -0600, Mike McNally wrote in reply:
> >On the other hand, the "algorithm" as presented is so hopelessly
> >obfuscated by the strange terminology and loose descriptions used ...
John Pettitt presents us with C code possibily matching the algorithm
(see the end of this email).
I imagine that John Pettitt may have written:
> I do not endorse the above code or algorithm and make no comment on it's
> strength or otherwise.
Well I spent 30 seconds on it. Do we get to start with known plain text?
This is the usual assumption these days. It so hopeless I imagine more
experienced cryptographers won't even bother replying.
DON'T USE THIS CODE.
It has a long cycle: (the product of all the c[i]) * 64
It can be broken into 64 parts and each part attacked separately.
Each part is the outputs with offset i modulo 64. Part i has a cycle
of c[i]. (Its irrelevant that the b[i] are prime, helps if they are
coprime to c[i].) There is no feedback between parts.
Each part looks like a LCM PRNG to me. The cryptanalysis of these was
done decades ago by Knuth. From memory the key can be deduced in a
known plain text attack with knownledge of about the same amount of
plain text as there is unknown key (initial state). (under 1K bytes).
Even without known plain text I suspect it would not survive past the
maximum c[i] (given some redundancy in the input).
I imagine that John Pettitt may have written:
> Here is my take on a C version of their code - note that a[] b[] c[] and the
> initial d are filled in from the 'one time pad'. The size of a,b,c is not
> specified it could be 8 16 or 32 bits from the text ... However the initial
> values of a,b & c are set using 8 bits of the 'random' key.
>
> int a[64] /* Random & 0x3500 */
> int b[64] /* Randomly selected primes */
> int c[64] /* randomly selected primes*/
> char d; /* random start value */
> int i;
>
> /* the arrays b,c are filled in from tables of smallish primes supplied
> by IPG using 'random' numbers supplied by IPG to select the primes (and the
> order of same). since all the values are > 8 bits I've assumed a,b,c = int.
> a[] is filled with 13568 + an 8 bit 'random' number. (13568 = 0x3500 which
> gets ANDed with the seed value)
> */
>
> while(1)
> {
> for(i=0; i<64;i++)
> {
> a[i] = (a[i] + b[i]) % c[i];
> d = (d+a[i]) & 0xFF;
> /* output d as next byte in stream */
> /* XOR with plaintext */
> }
> }
--
Munro Saunders Often seen at Gracelands, but ... P.O. Box 192,
[email protected] I am not an official spokesperson ERSKINEVILLE 2043
61 2 564 6368 for Elvis, IBM, M$ or Corinthian. AUSTRALIA