From: DataETRsch@aol.com
Date: Sat, 11 Jan 1997 09:06:32 -0800 (PST)
To: cypherpunks@toad.com
Subject: IMDMP 8192 PKCS and IMDMP Summary
Message-ID: <970111120551_1074845300@emout20.mail.aol.com>
MIME-Version: 1.0
Content-Type: text/plain


Hi,

You have probably read a few of my past messages about UDCM and IMDMP. The
variation of IMDMP implemented within UDCM V2.0 and UDCM V3.0 does not
include a public key cryptosystem. However, on March 1st, 1997, new versions
of UDCM and IMDMP will be released that do support the public key
cryptosystem method. The future versions will also support multi-party key
integration features, four platform independent random number generator
algorithms, as well as 1024 (8192 bit) keys. Note that the current version of
IMDMP only allows 256 byte (1024) bit keys. The current shareware version and
the future shareware version of UDCM will still only allow 5 byte (40 bit)
keys so as to comply with ITAR unless a key recovery infrastructure is
established. A public key directory infrastructure is being considered for
development as well. Also note that versions of UDCM are being planned for
the UNIX, DOS, and Macintosh System platforms.

There are a few major mistakes in a couple of my previous delegated messages.
An end-user application that supports IMDMP will not be released until March
1st, 1997. A detailed description of IMDMP will not be released as planned,
but, instead, the undocumented primary source code of UDCM (containing the
IMDMP encryption algorithm) will be released on February 1st, 1997. A
partially detailed summary of the IMDMP is now included in VENDOR.DOC file of
the UDCM V2.0 software package / archive. UDCM V2.0 was modified to restrict
keys to 50 bits so as to comply with the latest ITAR details. The extensively
confusing exportation restrictions sections of UDCM's documentation were
modified as well.

I am extremely sorry about the apparently extraneous information that is
present in a few of my first messages to this mailing list. Such a negative
level feedback was not anticipated. I do admit that single key encryption
methods are not too comparable to PKCS methods. What I was referring to when
I said IMDMP is more advanced than RSA, etc. is the actual encryption
procedure itself, not the way keys are secured. Again, irrashional claims
were not intended at all. The amount of analytical research invested in IMDMP
was thought to be sufficient.

By the way, has anyone out there even tried using UDCM to encrypt a file or
two? I do not know how some of you can say that IMDMP is a simple XOR-ing and
AND-ing algorithm without trying it first. I find it extremely hard to
believe that the celebrated creator(s) of Blowfish, IDEA, etc. had to go
through all of this ritualistic screening complexity too. (Please do correct
me if I am wrong.)

(For the record: DataET Research's promotional agent has been fired.)

Again, the web site address of UDCM is:
http://members.aol.com/dataetrsch/udcm.html. The web site includes has a link
to the VENDOR.DOC file which includes the aforesaid updated information.
UDCMV20.ZIP is currently unavailable on the web site as the software is
undergoing additional security modifications.

By the way, the web page's ugly background his been removed.

The IMDMP encryption algorithm itself combines various simple and complex
methods to secure digital data: standard randomized and fixed substitution,
standard randomized and fixed AND and XOR logic, integrated and interlaced
randomized XOR logic, NOT logic, randomized and fixed bit shifting,
randomized transposition scrambling, linear sequential bit incrementation and
decrementation, integrated and interlaced randomized and fixed byte
dependency structuring, sequential byte pyramid structuring, asymmetric
non-linear chaos and complexity based binary selection equation key
integration, anomalous key bit factoring, and continuous key bit modification
structuring. Sub-algorithms of IMDMP are basically additional applications of
one or more of the aforesaid techniques.

Questions, queries, or comments ("gulp")? E-Mail: DataETRsch@aol.com,
JKYuRamos@aol.com, or DataETResearch@geocities.com. Note: From now on, any
messages to DataET Research that do not contain the text "NO FLAME" somewhere
in the subject heading will be ignored completely. If a message is a indeed
flame, the associated server's administrator will be contacted, and a
complaint will be filed accordingly.

Thank you very much for your time.

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