1997-01-11 - Re: What!

Header Data

From: Murple <btherl@ikkles.cs.mu.oz.au>
To: cypherpunks@toad.com
Message Hash: ec9ec5cb61b50240373fec320a35933bb728a57e46bc86a3dd4c9d3c183adec3
Message ID: <199701112219.JAA07178@ikkles.cs.mu.oz.au>
Reply To: N/A
UTC Datetime: 1997-01-11 23:18:12 UTC
Raw Date: Sat, 11 Jan 1997 15:18:12 -0800 (PST)

Raw message

From: Murple <btherl@ikkles.cs.mu.oz.au>
Date: Sat, 11 Jan 1997 15:18:12 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: What!
Message-ID: <199701112219.JAA07178@ikkles.cs.mu.oz.au>
MIME-Version: 1.0
Content-Type: text/plain


> Excuse me?
> 
> What is faulty about IMDMP?
> 
> - Jeremy
> 

The only people who can answer that question are you and the good people at
DataET Research, the reason being that you are the only people who know what
IMDMP is.

A more appropriate question would be 'What is faulty about UDCM?'  The problem
is that to us, UDCM is like a 'black box' - we put data in, and data comes out,
but we have no understanding of what goes on to produce the data which comes
out.  IMDMP could well be more secure than all the cryptographic algorithms in
use today, but it could just as easily have huge security holes which we may
never know about, or at least not until it is too late.

The difference between this and public algorithms such as IDEA, is that we can
obtain source code, descriptions, comments, and often detailed analyses of
these algorithms, and we can decide for ourselves whether we want to entrust
our privacy to them.  With UDCM, and hence IMDMP, this is simply not possible,
and this is where I believe you have gone wrong.

Brian Herlihy





Thread