IMPORTANT: Additional information about UDCM.
![](https://secure.gravatar.com/avatar/015c7961adffb98899348ae7f6d61a7d.jpg?s=120&d=mm&r=g)
{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
![](https://secure.gravatar.com/avatar/5e3e364333b3d64055f6173fe5295da7.jpg?s=120&d=mm&r=g)
-----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-----
![](https://secure.gravatar.com/avatar/35060df691ee4d7eb2b448ee8ee34dff.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/132b650a0c58eb02865ec804064bf0ee.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/97203bfd409f2f1a362e4c1fa31c7a9d.jpg?s=120&d=mm&r=g)
{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.
![](https://secure.gravatar.com/avatar/1894a10a951ceb1ee502a205f9c858d1.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/1bb673879e664ae56d1f2346db54ceb3.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/35060df691ee4d7eb2b448ee8ee34dff.jpg?s=120&d=mm&r=g)
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
participants (7)
-
Black Unicorn
-
DataETRsch@aol.com
-
Eric Murray
-
ichudov@algebra.com
-
Mark M.
-
snow
-
Toto