1997-05-09 - One-Time Pads as Attack Method

Header Data

From: <00043.an@edtec.com>
To: <cypherpunks@algebra.com>
Message Hash: 82bbda8386ae1bd77273369c6fff4a5d030fca07c13b1c8a06e062fb02a13952
Message ID: <9705091650.AA19981@future.atlcom.net>
Reply To: N/A
UTC Datetime: 1997-05-09 17:13:53 UTC
Raw Date: Sat, 10 May 1997 01:13:53 +0800

Raw message

From: <00043.an@edtec.com>
Date: Sat, 10 May 1997 01:13:53 +0800
To: <cypherpunks@algebra.com>
Subject: One-Time Pads as Attack Method
Message-ID: <9705091650.AA19981@future.atlcom.net>
MIME-Version: 1.0
Content-Type: text/plain



1. Agents of the Enemy wish to create the appearance of you possessing
document A.
2. They obtain some artifact you have emailed, or posted, or possess on
your private local storage. ---
Possibly even signed.  Call this message B.
3. They create the XOR of A and B, the result being a 'one time pad' C.
which of course, gives:
private message B XOR C = target bogus message A.  This result is of course
not a one time pad;
the plan is to accuse you of possessing materials that prove you are
trading with the enemy,
exchanging kiddie-porn, any of the usual things.
4. This 'one time pad' file C. somehow finds its way into your possession:
it is an email attachment,
embedded in some binary --- it could even be stego'ed into a GIF/JPG.
5. The agents break down the door and seize all your effects.  
6. They are able to prove that you possess B and C, the XOR of which is A.,
a fact that is impossible
to have happened at random.
7. The jury doesn't know shit, and figures that if the chances of B ^ C = A
by accident are 0,
then you must be guilty.

I'm only looking at the general schema of an attack like this: I'm sure
there are many ways
the right defense could be mounted about how the files got on the client's
computer, etc.etc.

The interesting part of this frame-job is using something you may have
already publicly posted,
making denial of its origin difficult, together with a surreptitious
planting of the 'pad' data.

Naturally the incriminating data payload could be delivered directly,
without the OTP business.
But I thought it might be worth examining the implications of this theme.









Thread