From: "Mark M." <markm@voicenet.com>
Date: Thu, 9 Jan 1997 18:02:48 -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.LNX.3.95.970109205833.413A-100000@eclipse.voicenet.com>
MIME-Version: 1.0
Content-Type: text/plain


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