From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 15 Feb 94 19:49:47 PST
To: cypherpunks@toad.com
Subject: Stealth PGP
Message-ID: <9402160345.AA09186@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


Several people have talked about the possibility of doing a stealth PGP
by writing a filter to strip off the headers and another one to restore them.
It's an obvious approach, but depending on how good a job you want to do,
doing this independently of PGP is non-trivial.  Several issues:
- Doing a halfway job is pretty easy, but won't fool much of anyone rich and
  serious enough to de-steg every GIF or JPEG floating across the net,
  especially in countries that most need it, where telecommunications
  is narrowly controlled and legal procedures are irrelevant.
  On the other hand, deleting the PGP-ENCRYPTED-STUFF headers is 
  enough to get you through a No-Encryption-Permitted BBS mailnet.
- Each block of stuff starts with a Crypto Block Type byte and length info.
  For some blocks, including the first one or two, you know the block type
  (at least for the interesting cases), and could force the length to
  some standard length by assuming a maximum and doing a fixed format.
  Applying this to the multiple-recipients case is harder.

- The public key block includes a 64-bit Key ID to tell PGP which key
  to use and whether to bother decrypting (if it's not for you.)
  You could omit this information, and on receipt put your own key in,
  but that does lose the ability to tell whether it's for you.
  I'd have to look at the PGP code a lot more to see if it would really mind.
  The right way to solve this problem would be to include a string
  easily recognized if you have the right public key and meaningless
  otherwise, such as a 64-bit random number repeated twice, encrypted with
  the recipient's public key, but at that point you need to involve
  the PGP code itself, since the sender needs to know the recipient's
  public key and how to encrypt with it, and the receiver needs to
  scrounge the private key out of the secret-key-ring with the passphrase.

- The other block-types have similar problems, but once you've incorporated
  the new format with PGP, you could include any needed masking info
  in the first block.  Hiding the block type and length is probably enough.

- The formats are of course all different for non-encrypted messages with
  signatures, etc., ascii-armored or not, and other problems.

- At one time somebody had said there was work going on about a new
  version of PGP somewhere outside the US patentspace, and had said
  that they were thinking about solving this problem as well as integration
  with MIME.  That make this a Somebody Else's Problem, and, uhh,
  I forget what the rest of the problem was... :-)

			Bill
			
# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399
# email bill.stewart@pleasantonca.ncr.com billstewart@attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465