First, re: "self decrypting" binaries.

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!

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

Sounds more like a general utility for conventional key crypto with versions ported to other platforms. Like pkzip's "crypto" options, but hopefully without publicly posted programs to crack it! Imagine a program built with lharc, zip, arj, tar, uuxfer, md5, and idea. A general file cruncher. Then you send a binary .whatever file with a special header that has the passphrase prompts you've decided on. Not "self-decrypting" by any means, but more likely to be run and accepted by a user unwilling to install pgp. Also, very easy to write. Hork gzip, maybe info-zip, pgptools, maybe some lharc code, etc from publicly visible locations and snap them together. I have to agree with the statement that I'm NOT going to run a random binary dropped in my mbox! Even if someone I'd like to communicate securely with had said it'd be dropping by. I think with all the talk about steg lately we might want to recall an idea posted a few months (several?) ago.... Create and widely distribute a program to take a "stealth" crypto file (of course, the util might also do the stealthing.... details) and perform a large number of manipulations on it. Something like a command blend -"Hello, world!" file.bin would do something like use the "H" option (of MANY) with an argument of 5 (or of 101 or whatever the ascii value of 'e' is... I'm tired), then the "l" manipulation twice ("l" might not take an argument), then "o", skip the comma and whitespace (or maybe not), etc. No way to gaurantee that some operations don't undo one another, but you'd still have a good chance that the resulting file would be VERY difficult to cryptanalyse, I think (and I *know* I'll be told if I'm wrong... I'm repeating what seemed like a good idea). At the very least, it wouldn't decrypt into anything useful. This way, one utility can provide man avenues to help steg (if the file cannot be determined to be encrypted by a particular program/with a particular method, it may be easier to hide in a practicable way (which may be less secure than a more theorhetically sound method)). Again, I'm in favor of having the program also provide a non-crypto related service to the user. Encourage people to have it and know how to use it, and provide a cover to explain it's presence. Just a couple-a comments on current threads. Seth Morris (Seth.Morris@LaUNChpad.unc.edu)