From: snow <snow@smoke.suba.com>
Date: Thu, 9 Jan 1997 21:19:52 -0800 (PST)
To: DataETRsch@aol.com
Subject: Re: IMPORTANT: Additional information about UDCM.
In-Reply-To: <970109181113_1044501439@emout15.mail.aol.com>
Message-ID: <199701100535.XAA00734@smoke.suba.com>
MIME-Version: 1.0
Content-Type: text/plain


> {Please read this *entire* e-mail message.}
> Hi,
> this mailing list within a few days. An end-user application will be released
> within a few weeks. I would appreciate it if all you cypherpunks out there
> review the description and the software, and tell me what you think of IMDMP.

     I think I can speak for all of us when I say we are waiting with baited 
breath. 

     Yes, Virginia, that _is_ sarcasm. 

> Also: The AOL web site address my company has may not always work out when
> the server is having problems or user overloads. Please try again later.
> Again, the web site address for UDCM, Universal Data Cryptography Module, is:
> http://members.aol.com/DataETRsch/udcm.html.

     For $100 up front, and about $40 a month you can get a real domain name
and virtual domain that doesn't have a problem with "user overloads". If 
you are so high tech, why are you using AOL for a WEB SERVER? (this is a 
seperate issue from using it for _access_)

> IN RESPONSE TO THE FLAME MAIL DATA RESEARCH HAS BEEN RECEIVING:
> Note: The 18 "sub-algorithms" of IMDMP are basically algorithm "modes", and,
> yes, many algorithms do *not* have multiple encryption layers, although,
> obviously, the more advanced ones do. Also, 256 bytes is equal to 2048 bits.
> I realize that most of you out there know that, but some of you don't. "Bits"
> are referenced more often than "bytes". And, the "industry standard" that
> IMDMP is obviously well above is DES, etc. Also, DES 128, PGP 1024, RSA 128,

     With certain versions of PGP (or rather with non-us versions of certain
libraries used by PGP) you can get much larger keys than 1024. In fact with 
2.62 you can (IIRC) do 2048.

> IDEA 128, and IMDMP 2048 were applied at their maximum settings on a file
> full of about 64 *million* repeating "A" ASCII character bytes. The mutation

     

> levels the algorithms rendered on their individual trash test files were
> compared. Subtle patterns where searched for. Binary character tallys where
> taken. IMDMP did *not* leave *any* repeating patterns in the test file that
> was used. In IMDMP, each of the 256 possible binary character combinations
> had an approximate count of  0.390625% of all of the 64 million bytes.
>  0.390625% is the best possible percentage. Are all of you out there
> satisfied?

     Well, just for fun, I wrote a short C program that wrote a file of 
64,000,000 A's, and ran it thru PGP with a key size of 1024, and grabbed the
pre-ascii armor version of it. I looked thru it, and no obvious patterns 
were there.

    PGP must use a pretty good compression algorythm(sp?) since the gzip of
the A's file is only about 13 bytes longer than the gzip version. A second 
pass of gzip gives me a file of 289 bytes.

    In fact, I would doubt that any half way decent encryption program _would
show repeating worth a damn, compression should take care of most of the 
*obvious* patterns in normal text. 2 or more passes should handle anything
deliberately (or naturally) pattern heavy. 

    So no. I am not impressed. Post the code, pay OUTSIDERS to look at your
code. Get it banned by the NSA, _then_ I'll be impressed.