From: Munro Saunders <munro@ci.com.au>
Date: Wed, 20 Mar 1996 11:34:26 +0800
To: jpp@software.net (John Pettitt)
Subject: Re: IPG - newest release of the ABC Encryption Algorithms (fwd)
In-Reply-To: <2.2.32.19960319175044.00c7bab8@mail.software.net>
Message-ID: <199603192306.KAA02258@mippet.ci.com.au>
MIME-Version: 1.0
Content-Type: text/plain


> >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,
munro@ci.com.au   I am not an official spokesperson     ERSKINEVILLE 2043
61 2 564 6368     for Elvis, IBM, M$ or Corinthian.     AUSTRALIA