1995-09-13 - Re: Scientology tries to break PGP - and

Header Data

From: “Henry W. Farkas” <hfarkas@ims.advantis.com>
To: “David R. Conrad” <ab411@detroit.freenet.org>
Message Hash: 604e98dcbf101580d5842d511e09b0364d01667ce3729bbd342167d645e52d4d
Message ID: <Pine.A32.3.91.950913102622.32299A-100000@pangloss.ims.advantis.com>
Reply To: <199509131332.JAA29256@detroit.freenet.org>
UTC Datetime: 1995-09-13 14:46:06 UTC
Raw Date: Wed, 13 Sep 95 07:46:06 PDT

Raw message

From: "Henry W. Farkas" <hfarkas@ims.advantis.com>
Date: Wed, 13 Sep 95 07:46:06 PDT
To: "David R. Conrad" <ab411@detroit.freenet.org>
Subject: Re: Scientology tries to break PGP - and
In-Reply-To: <199509131332.JAA29256@detroit.freenet.org>
Message-ID: <Pine.A32.3.91.950913102622.32299A-100000@pangloss.ims.advantis.com>
MIME-Version: 1.0
Content-Type: text/plain


On Wed, 13 Sep 1995, David R. Conrad wrote:

> And the idea is that on decrypting with the 'wrong' key, it outputs the
> dummy file rather than the real plaintext, correct?

I'll say it again.  :-)

PGP could allow for an alternate secret key and a standard "dummy"
document from somewhere in your path.  A command line option would encrypt
for both keys (as if there were 2 recipients) and append the "dummy"
document to the end of the target file when encrypting. 

If decrypted with the "alternate" or "fake" secret key, the encrypted file
is wiped until it reaches a marker; the remainder of the file is
displayed.  If you use your "primary" or "real key", the extraneous text
is simply stripped. 

Alternately, the "dummy" file could overwrite the "real" message n times, 
to keep the decrypted file size more realistic.

> Why would they use your copy of the program to decrypt the file?  They
> could just use a version that lacked this 'feature'.  
A good point.  A new version of pgp would have to be incompatible with 
older versions.  That's a Very Big Hassle, I know.  But consider the 
advantage.  Nobody who has your secure key can prove that it's not the 
"real" secure key and that the decrypted file is not the real plaintext.  
They may "know" it but they can't prove it.  All they can do is force you 
to hand over *-a-* key that will decrypt the file. 

> Of course, they
> still couldn't get at the real plaintext unless you gave them the key,
> but you are right back to the same old standoff where they say, "Give
> us your key," and you (try to) say, "No."

Well yes, that is the point I'm trying to address.  The key you finally
give them *is* your secure key.  Just not the key under the blender.  They
will have a hard time arguing "But that's not what the file *really* said
and, deep inside of me, I know it!".  

I say again:  All they can do is force you to hand over *-a-* key that will
decrypt the file.  "You cannot force a mind." - J. Galt -

     Henry W. Farkas      |      Me?    Speak for IBM?    Fat chance.
 hfarkas@ims.advantis.com |------------------------------------------------  
   hfarkas@vnet.ibm.com   |     http://newstand.ims.advantis.com/henry
      henry@nhcc.com      |          http://www.nhcc.com/~henry 
- ---------------------------------------------------------------------------
PGP 6.2.2 Key fingerprint: AA D0 F5 44 C1 8C 11 52  B3 80 34 1C CE 38 EC 53
 Public key at: pgp-public-keys@pgp.mit.edu, and other popular key servers.
- ---------------------------------------------------------------------------
Brought to you by Henry's Hardware: Home of the Pretty Good Hack "We're not
  fast, but it's not bad, and we're cheaper than the guy down the street!"

Version: 2.6.2
Comment: Auto-signed with Bryce's Auto-PGP v1.0beta