[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "self decrypto" and Steg
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 ([email protected])