From: Black Unicorn <unicorn@schloss.li>
To: DataETRsch@aol.com
Message Hash: b5d633f61de8d25e73108fc6075af49aa792f577465a344f5e676ebb2683a9e0
Message ID: <Pine.SUN.3.94.970109235122.5558E-100000@polaris>
Reply To: <970109181113_1044501439@emout15.mail.aol.com>
UTC Datetime: 1997-01-10 05:08:09 UTC
Raw Date: Thu, 9 Jan 1997 21:08:09 -0800 (PST)
From: Black Unicorn <unicorn@schloss.li>
Date: Thu, 9 Jan 1997 21:08:09 -0800 (PST)
To: DataETRsch@aol.com
Subject: Re: IMPORTANT: Additional information about UDCM.
In-Reply-To: <970109181113_1044501439@emout15.mail.aol.com>
Message-ID: <Pine.SUN.3.94.970109235122.5558E-100000@polaris>
MIME-Version: 1.0
Content-Type: text/plain
On Thu, 9 Jan 1997 DataETRsch@aol.com wrote:
> Date: Thu, 9 Jan 1997 18:11:18 -0500 (EST)
> From: DataETRsch@aol.com
> To: cypherpunks@toad.com
> Subject: IMPORTANT: Additional information about UDCM.
>
> {Please read this *entire* e-mail message.}
>
> Hi,
>
> A detailed description of the IMDMP encryption algorithm will be posted to
> 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.
This entire thread makes me want to suggest a set of guidelines for people
who are going to try and submit untested crypto software to the list so we
don't have to do this every 2 weeks.
In any event this is a good start.
[...]
> 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 dont believe this is quite what you mean.
I think you are confusing two kinds of cyphers (public and otherwise) with
each other and attributing for the difference in key measurements
(actually caused by the different keyspace for prime number based
public key systems) by using bytes and bits.
This does not bode well for your crypto expertise, if in fact this is what
you are doing.
> I realize that most of you out there know that, but some of you don't. "Bits"
> are referenced more often than "bytes".
I dont really think anyone uses bytes to refer to key size, except perhaps
in Prime Number challenges (RSA-129).
> And, the "industry standard" that
> IMDMP is obviously well above is DES, etc.
How is this obvious?
> Also, DES 128,
I'm not sure DES 128 exists.
> PGP 1024, RSA 128,
> 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?
No.
A simple entropy test does not a cypher make. I'd also like to know what
patterns were tested for as certainly I know of no test which can prove
that a given set of data does not have "*any* repeating patterns."
Entropy is subjective. Perhaps it encodes stuff in Estonian. There may
not be recognizeable patterns in english, but there certainly will be
patterns. Perhaps its output exactly mimics the radiowave noise from
Alpha Centauri between 10pm and 10:00.0056pm January 1. You can't show me
it doesn't, and if you could I could just invent a new pattern to get you
to test. (How many angels....)
Can't prove a negative (there are no patterns in here).
Your cypher has obviously undergone a lot of work. This too does not a
cypher make. Nor does your hype. That usually a cypher unmakes, in fact.
My suggestion: Full disclosure on your cypher coupled with a reduction in
the sales and marketing rhetoric that we are getting from you. (You might
try a non AOL address too, adds a bit more respectability).
> Jeremy K. Yu-Ramos
> President
> DataET Research
> Data Engineering Technologies
>
--
Forward complaints to : European Association of Envelope Manufactures
Finger for Public Key Gutenbergstrasse 21;Postfach;CH-3001;Bern
Vote Monarchist Switzerland
Return to January 1997
Return to “Toto <toto@sk.sympatico.ca>”