1994-02-25 - Re: self-decrypting messages

Header Data

From: cort@ecn.purdue.edu (cort)
To: warlord@MIT.EDU (Derek Atkins)
Message Hash: ff3dd9ffd9345854661deac00f1ccb8a225b550e2d4efe5f107fa9f1dcdb59c6
Message ID: <9402250137.AA08458@en.ecn.purdue.edu>
Reply To: <9402250120.AA12855@toxicwaste.media.mit.edu>
UTC Datetime: 1994-02-25 01:38:15 UTC
Raw Date: Thu, 24 Feb 94 17:38:15 PST

Raw message

From: cort@ecn.purdue.edu (cort)
Date: Thu, 24 Feb 94 17:38:15 PST
To: warlord@MIT.EDU (Derek Atkins)
Subject: Re: self-decrypting messages
In-Reply-To: <9402250120.AA12855@toxicwaste.media.mit.edu>
Message-ID: <9402250137.AA08458@en.ecn.purdue.edu>
MIME-Version: 1.0
Content-Type: text


> 
> An interesting idea, although highly unpracticable.  Sending a binary
> is nearly impossible.  As an example, I have at my disposal (and I log
> into regularly) at least 6 different platforms.  All Unix, but each
> one would require its own binary!

I assume you mean embedded binary (under radix 64).  In Unix land,
uudecode could be assumed or a script version of radix decoding
could run against itself.

You are quite correct in assumption of platform.  This is a bummer.
The ubiquity of DOS makes this a bother rather than a block.  (I'll
bet even you at least _see_ a DOS box occasionally!  :)

> 
> This doesn't mean that your idea has no merit.  On the other hand, it
> is an interesting key distribution model.  Except there are a number
> of problems that I can see.  First, anything you know about the person
> is something that someone else could probably do a little research and
> find out as well.  This inherently means it is not a very secure
> channel, rather it is only moderately secure.

"Ida, remember our last conversation....  who were we talking
about?  (Please provide full name properly capitalized.)"
"Ida, you and I were reading the newspaper in the break room the
other day.  We discussed a point of mutual interest.  What was it?"

The less intimately I know the recipient, the tougher it is to
formulate a good question.

I agree, moderately secure.

> 
> Also, there is no way to meet your goal of "no external binary
> needed."  There may be a few things you can do in lieu of this, but
> all of them require some knowledge of the recipient hardware system.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes.  :(

> But in a case such as mine, even that wouldn't help (do you send it
> for an RT, Vax, Decmips, RS6000, Alpha, Linux, Sun386i, Next, ...?)
> 
> Like I said, its an interesting key distribution model, but I do not
> see any way to realize it under your assumptions.
> 
> -derek
> 
> 





Thread