No Subject

Kinda-Fair-Secret Message Passing
                           -OR-
                  Self-Decrypting Messages


I have an IDEA.  It may have already been thought of....

Problem:
  - PGP is great, but like so many infant technologies,
    encryption programs are not quite "turnkey".
  - Many people do not have PGP installed.  I want to send
    messages to some of these people.  (Oh, I know, a true
    geek doesn't bother to communicate with PlaintextPunks!)

Solution:
  - Securely encrypted messages with programmable "key
    question" and "response key" for self-decryption.

Scenario:
  Fred wants to send a message to Ida.  Fred is a cypherpunk
  and is quite proficient with PGP.  However, Ida is not
  set up with PGP and does not desire to learn PK cryptography.
  Fred and Ida know each other (or something about each other).

  Fred sends a self-decrypting message to Ida in an executable
  file.  Ida simply receives the file and executes it.  (This
  is analogous to self-extracting zip files.)

  When the file is executed, it will ask Ida a question that Fred
  has set up (with her in mind).  This question will ideally be
  answerable only by Ida.  If Ida answers correctly, her response
  will form a key to decrypt the message.

I have thought a bit about the implementation.  It seems that
it may be pretty simple to do using PGP Tools.  The passphrase
recognition could use a one-way function (MD5?).  IDEA could
be the encryption algorithm.  RSA is not needed.

The tricky part is providing an executable file while providing
a little bit of instruction at the front of this file (to instruct
the recipient to down-load and execute).

Also, it seems that an assumption of recipient platform (e.g. DOS,
Unix, etc.) may be necessary.  Uuencoding or similar ASCII/binary
conversion may be required.

Comments?  Would someone do this?  Does it already exist?

It would be a nice augmentation to the PGP package!

Cort.
-- 
cort@cc.purdue.edu

On Thu, 24 Feb 1994, cort wrote:

>   When the file is executed, it will ask Ida a question that Fred
>   has set up (with her in mind).  This question will ideally be
>   answerable only by Ida.  If Ida answers correctly, her response
>   will form a key to decrypt the message.


There might be a problem in that Ida would have to phrase the answer
_exactly_ in the way that the sender has anticipated it would be phrased.

For example, Fred might ask:

"Where were we when we first kissed?"

Ida may answer:

"In the back of a dumpster truck"

Although correct, Fred may have anticipaded:

"In a dumpster truck"


There has to be a provision for unambiguous wording.  Even a question as
simple as:

"How old are you?"

may be answered in more than one way

"99"

"ninety-nine"

"99.5"

"ninety-nine and one half"

Knowing the answer yet having the program reject the "correct" answer 
time after time may frustrate your PGP-Self-Decrypt unaware user.

> It would be a nice augmentation to the PGP package!
> 

Why use PGP?  As I understand it, the virtue of PGP lies in it's 
handling of public and secret keys.  Any semi-secure algorythm may be 
used with a self-decrypt program.

> Cort.
> -- 
> cort@cc.purdue.edu
> 


Sergey

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!

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.

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

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

Although I'm still uncomfortable about the non-crypto user key, there is
a simple solution to the problem of executable/data transmission:

Send it as Perl, Postscript, Tcl, whatever.

Perl should be able to handle an encode (7 bit) data stream with a
program prepended.  The algorithm would be more obvious, but
technically no more secure if you disallow security-through-obscurity.

Perl is available almost everywhere, is reasonably fast, has a
comprehensive capability list, etc.

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

This is what I think is rough.

> 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.
> 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, ...?)

Perl...

> Like I said, its an interesting key distribution model, but I do not
> see any way to realize it under your assumptions.
> 
> -derek


sdw
-- 
Stephen D. Williams  Local Internet Gateway Co.; SDW Systems 513 496-5223APager
LIG dev./sales       Internet: sdw@lig.net sdw@meaddata.com
OO R&D Source Dist.  By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Comm. Consulting     ICBM: 39 34N 85 15W I love it when a plan comes together

> Although I'm still uncomfortable about the non-crypto user key, there is
> a simple solution to the problem of executable/data transmission:
> 
> Send it as Perl, Postscript, Tcl, whatever.

You are assuming that I (I being every possible recipient) have PERL
available!  While in my particular case this is probably not a bad
assumption, it is a horrible assumption in the long-run.  What about
people with their 20M IBM PC-XT DOS machines?  They probably don't
have PERL.  And I *know* that most Mac users do not have PERL.

I'm not saying that PERL would be a bad thing to use.  You could also
theoretically use sh and cc!  But the problem is you have to assume
that *every* user has these available, and that is a bad assumption.
If you are going to assume that, you might as well assume that they
have PGP and save all the trouble!  Why not just assume they have PGP
and generate a file which will execute PGP on itself?  That solves the
problem, and is secure. (Well, it doesn't solve the problem of a user
running a random exacutable sent in the mail).

BTW: I must apologize for interchanging "binary" for "exacutable"...
I tend to do it a lot, and in the context I confused the topic.  When
I said that the problem was sending a binary for every machine, I
meant the problem was creating something that could execute on every
machine.  While PERL is a compromise, it is definitely not the panacea
to this problem.  Do you want to target certain architechtures?  I
hope not.

Just use PGP.  Remember, PERL is the wrong solution to every problem. ;-)

-derek

         Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
       Member, MIT Student Information Processing Board (SIPB)
         PGP key available from pgp-public-keys@pgp.mit.edu
            warlord@MIT.EDU       PP-ASEL        N1NWH

> 
> > Although I'm still uncomfortable about the non-crypto user key, there is
> > a simple solution to the problem of executable/data transmission:
> > 
> > Send it as Perl, Postscript, Tcl, whatever.
> 
> You are assuming that I (I being every possible recipient) have PERL
> available!  While in my particular case this is probably not a bad
> assumption, it is a horrible assumption in the long-run.  What about
> people with their 20M IBM PC-XT DOS machines?  They probably don't
> have PERL.  And I *know* that most Mac users do not have PERL.

All of those will run perl and it is much more readily available.
For most Unix systems, Perl is there by default.  (If the sysadmin 
does much.)

It is an improvement over MSDOS executables.

> Just use PGP.  Remember, PERL is the wrong solution to every problem. ;-)

Could be.  I'm not a Perl expert yet, but I'm working on adding it to
my multitude of languages.

> -derek

sdw
-- 
Stephen D. Williams  Local Internet Gateway Co.; SDW Systems 513 496-5223APager
LIG dev./sales       Internet: sdw@lig.net sdw@meaddata.com
OO R&D Source Dist.  By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Comm. Consulting     ICBM: 39 34N 85 15W I love it when a plan comes together

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

cort@ecn.purdue.edu wrote:

>  Fred wants to send a message to Ida.  Fred is a cypherpunk
>  and is quite proficient with PGP.  However, Ida is not
>  set up with PGP and does not desire to learn PK cryptography.
>  Fred and Ida know each other (or something about each other).
>
>  Fred sends a self-decrypting message to Ida in an executable
>  file.  Ida simply receives the file and executes it.  (This
>  is analogous to self-extracting zip files.)
>
>  When the file is executed, it will ask Ida a question that Fred
>  has set up (with her in mind).  This question will ideally be
>  answerable only by Ida.  If Ida answers correctly, her response
>  will form a key to decrypt the message.
...

> The tricky part is providing an executable file while providing
> a little bit of instruction at the front of this file (to instruct
> the recipient to down-load and execute).
> 
> Also, it seems that an assumption of recipient platform (e.g. DOS,
> Unix, etc.) may be necessary.  Uuencoding or similar ASCII/binary
> conversion may be required.
> 
> Comments?  Would someone do this?  Does it already exist?
> 
> It would be a nice augmentation to the PGP package!

All sounds great, but there is one problem - Ida has to download the
file, uudecode it and run it.  I don't see how that's any easier than
downloading it and running pgp...  If Ida is computer-illiterate and
can't download a file and decrypt it with pgp, it wouldn't be reasonable
to expect her to download it and run uudecode.

I think you may have a good idea here, but it's not really ideal for
cryptography.  As Thomas Edison was fond of saying, just because
something doesn't do what you want doesn't mean it's useless.  Perhaps
you should consider the project from a different approach - such as for
self-extracting graphical email.  I know a lot of people who would like
to be able to doodle graphical images in their email, as well as a lot
of hardware hackers that would like to draw circuit diagrams and such. 
Seems like self-extracting graphical email would be ideal for these
purposes.  And of course, you would want to protect it with crypto too.
:)