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
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. :)
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!
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
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
participants (5)
-
cort＠ecn.purdue.edu -
Derek Atkins -
Matthew J Ghio -
sdw＠meaddata.com -
Sergey Goldgaber