Re: Weak stenography.

One thing keeps bugging me about steganography. Let's say that
"unlicensed cryptography", including the mere possession of ciphertext,
is totally outlawed. You may well be able to bury encrypted data in all
sorts of things (gif files, digital audio, "free" blocks on a hard disk,
etc). But if you ever want to be able to retrieve it, you have to leave
yourself an Achilles Heel: somewhere you need to keep a computer
program, in plaintext, that you can execute to extract and decrypt the
hidden ciphertext.

You may be able to get away with claiming that the low order bits of
your Doors tapes really *are* meaningless random bits picked up when you
dubbed all your worn-out LPs to DAT, but if they find "readdat.exe" on
your PC, disassemble it and discover that it's a program to extract and
decrypt ciphertext from DAT tapes, you're in trouble. And if you encrypt
your copy of "readdat.exe", well, you now need a plaintext decryption
program to decrypt THAT.

Short of devising a scheme that's so simple that you don't mind recoding
it from scratch (and from memory) every time you want to extract and
decrypt something, what can be done?

Phil

Phil Karn writes:
...
> etc). But if you ever want to be able to retrieve it, you have to leave
> yourself an Achilles Heel: somewhere you need to keep a computer
> program, in plaintext, that you can execute to extract and decrypt the
> hidden ciphertext.
> 
> You may be able to get away with claiming that the low order bits of
> your Doors tapes really *are* meaningless random bits picked up when you
> dubbed all your worn-out LPs to DAT, but if they find "readdat.exe" on
> your PC, disassemble it and discover that it's a program to extract and
> decrypt ciphertext from DAT tapes, you're in trouble. And if you encrypt
> your copy of "readdat.exe", well, you now need a plaintext decryption
> program to decrypt THAT.
> 
> Short of devising a scheme that's so simple that you don't mind recoding
> it from scratch (and from memory) every time you want to extract and
> decrypt something, what can be done?

Some solutions:

1. Make programs like "readdat.exe" ubiquitous...distribute them on
shareware disks, CD-ROMs, etc. Thus, many households and offices will
have "readdat.exe"-like programs, whether they use them or not. Mere
possession of such a program will thus not be unusual or
suspicion-provoking. (This is of course one of the strategies in
making PGP and related programs ubiquitous.)

(Note that the storage of the _key_ is another matter, and is a
problem with most crypto schemes. For data stored in low-order bits on
a DAT, and retrievable with "readdat.exe," a pass-phrase of sufficient
length can be used.)

2. The bit-reading program "readdat.exe" can be stored remotely,
perhaps at an ftp site, so the user can retrieve it only when he needs
to use it, then flush it.

(I favor the "ubiquitous" route, as frequent retrievals make
themselves known in other ways....and may even draw attention to a
user in the first place.)

-Tim May



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | Public Key: PGP and MailSafe available.
Note: I put time and money into writing this posting. I hope you enjoy it.

>> 1. Make programs like "readdat.exe" ubiquitous...distribute them on
	Well, you need a program to read your DATs and play them
anyhow. What's a few extra options? Presumably it would handle various
filtering and sampling anyhow; perhaps the common DAT tools or audio
tools could just happen to contain a bit slicer... 
	Still doesn't sound like it's useful for anything you need to
access alot or use in the short term. Best to keep fighting for real
privacy...

>> I must admit I'm disappointed to hear Hellman say something like this.
>> Every time somebody comes up with a "new" or "improved" key escrow scheme,
>> they give implicit approval to the whole basic idea of key escrow. Which
>> is fundamentally unacceptable in *any* form.
	It could be said that this focusses the argument on the real
issue... which is *not* the technology, but the trust of government
(or the need for it.) 
	Perhaps this analogy isn't too stretched: suppose your child
wants to keep a private diary. They can keep it under two locks -- but
only if mother has one key and father has the other (so that if they
agree that they need to see the diary, they can.) Does this seem fair
itself? [too many would argue yes... that as the parents are
responsible for the child, it is reasonable to do this] Does this seem
like a good analogy? [perhaps closer than some would like to admit...
"but mother and father are closer than any escrow agencies would
be..." "oh really?" etc.]
							_Mark_

Phil Karn:
> if they find "readdat.exe" on
> your PC, disassemble it and discover that it's a program to extract and
> decrypt ciphertext from DAT tapes, you're in trouble. And if you encrypt
> your copy of "readdat.exe", well, you now need a plaintext decryption
> program to decrypt THAT.

Perhaps some hacks (ab)used by virus writers might be useful here.
We might hide "readdat.exe" inside a larger "innocuous.exe" and
scramble it with the "mutation engine", which creates a unique signature 
for each copy of readdat.exe's code (including the engine itself, which
bootstraps from a very short common code sequence).  The result 
is they have no signature to search for, even if they already have 
a copy of "readdat.exe" and the mutation engine.

Nick Szabo				szabo@techbook.com