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.


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.

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,
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?

Jeremy K. Yu-Ramos
President
DataET Research
Data Engineering Technologies

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 9 Jan 1997 DataETRsch@aol.com wrote:

> 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.

Please explain what a mode is.  "Mode" usually refers to ECB, CBC, CFB, etc.

> And, the "industry standard" that
> IMDMP is obviously well above is DES, etc.

Do you have any proof to back this up?

> Also, DES 128, 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.

PGP isn't an algorithm.  And RSA 128 is _extremely_ insecure.  How exactly did
you get DES to use a 128-bit key?  Perhaps you used some variant of DES, but
you did not specify.  Also, I'm curious as to why you compare IMDMP, which is
(probably) a symmetric algorithm with public key algorithms.  They really
aren't comparable.

> 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.

Just because ciphertext passes simple randomness tests does not mean that the
algorithm used to encrypt it is secure.  If ciphertext does not appear to be
random, then the algorithm is not secure.  It doesn't work the other way
around.

>  0.390625% is the best possible percentage. Are all of you out there
> satisfied?

Not especially.  I'd still be interested in the design criteria used to develop
this algorithm.  Until you publish the full source and technical data, I will
have to assume that the algorithm is insecure.


Mark
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQEVAwUBMtWkCSzIPc7jvyFpAQE1Fgf9HNCgJ8Rp/F0JcxDi2seWN/l9wCvm97s3
woPB4F+nOVnhmkGNqhf1HfzBFNvaUzp9n/JsLnWU1MS5P0vtPCAxTbrNncuiMlId
OHulFWeFePJUcG6peORKAtIcndZ47KpwQB8YlQ1bzWtqPs+KcfVfpPJHDjrO2/9C
rD0HebdxSz3DpsBlK+Wj9M57R0RHQjL1r5nShXz0Dx0Z1oMy1FhuGvRlYhl8q2Z6
sElyVOklPTxjdKTuHjhlBIy5mEK/+56jBju9/njY6+S05L+3I+uffVXIKsH07QJF
v8ReB9EnSOubBNxKgkfh5L6KHrvm3UZVY8dwJPsZFxGbsKAs1Gl7xQ==
=s8rX
-----END PGP SIGNATURE-----

Mark M. wrote:
> On Thu, 9 Jan 1997 DataETRsch@aol.com wrote:
> 
> > IN RESPONSE TO THE FLAME MAIL DATA RESEARCH HAS BEEN RECEIVING:

  The 'flames' used as examples seemed to me to be nothing more than
valid questions regarding the DataETR's claims for their software.

(Big Hint / Questions from conferences with the word 'punks' in the
name are not likely to be accompanied by bowing gestures and
exclaimations of amazement at unsubstantiated claims).

> >  0.390625% is the best possible percentage. Are all of you out there
> > satisfied?
> 
> Not especially.  I'd still be interested in the design criteria used to develop
> this algorithm.  Until you publish the full source and technical data, I will
> have to assume that the algorithm is insecure.

  Keep in mind that many CypherPunks dream in numbers.

Toto

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

> {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.

snow writes:
> 
> > 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_)

You would think that a company that could issue "$1,250,000 in collateral
backed zero-coupon bonds" would be able to afford a real web site.

 
> > 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.

Obviously.

> Also, 256 bytes is equal to 2048 bits.

Thank you, I was wondering about that.

> > 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,

"industry standard"?  Which one, pray tell?


> > Are all of you out there satisfied?

No, not until your algorithm is made public and has been reviewed
by people who know what they are doing.  Most prudent crypto application
developers wait a few years after a new algorithm has been made public
to see if someone discovers flaws in it.

Unfortunately for you, the way you are announcing and promoting your
program makes it could like cryptographic snake oil.  Posting
such announcements to the cypherpunks list is a good way to get flamed.
Perhaps you should have posted to alt.biz.multi-level, where the
threshold of credulity is much higher.


-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Eric Murray wrote:
> snow writes:
> > > 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_)
> 
> You would think that a company that could issue "$1,250,000 in collateral
> backed zero-coupon bonds" would be able to afford a real web site.

Mmmm... What is the collateral? Intangible assets like distribution roghts?

Also, this guy's web site is totally fucked up -- the lines in 
http://members.aol.com/dataetrsch/public/udcmv20b.txt are
very long and browsers are not supposed to wrap them.

I am also wondering, I am listed as visitor 189 on his web site. Under
most optimistic assumptions, if *every* visitor bought his product, he would
have made $40*188 = $7520.

A good money, no doubt, but to issue $1,250,000 worth of *zero-coupon* 
bonds?

	- Igor.

Eric Murray wrote:
 
> Unfortunately for you, the way you are announcing and promoting your
> program makes it could like cryptographic snake oil.  Posting
> such announcements to the cypherpunks list is a good way to get flamed.
> Perhaps you should have posted to alt.biz.multi-level, where the
> threshold of credulity is much higher.

  I suppose that after moderation begins, we will miss DataETRetch's
next big update, since they will take your suggestion to heart
and title their next posting, "Make Big Cryto$$$".

Toto