RE: IMPORTANT: Additional information about UDCM.

[Blake Coverett <blake@bcdev.com>]

Welcome once again to your weekly round of 'Smell that Snake Oil'

> 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 is a good start.  You would do well to keep your wild claims to a
minimum until after the first cursory reviews.

> 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

DES 128 - no such beast
PGP 1024 - this is presumably a RSA key size, and has nothing
to do with the session key involved in actually encrypting the data
RSA 128 - RSA is not suited to encrypting streams of data but if
you wanted to use it for that purpose 128bits would be ridiculusly
to small to be secure
IDEA 128 - wow, you've actually named one real block cipher!
IMDMP 2048 - feh

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

The fact that you would consider this to be a sufficient test is proof enough
for me that you should not be designing cryptosystems.

> Are all of you out there
> satisfied?

Not even close.

-Blake 
(who's waiting for the first pyramid-scheme cipher to be announced here next week)