[117574] in Cypherpunks
Better OTP
daemon@ATHENA.MIT.EDU (Sean Roach)
Mon Sep 6 13:16:54 1999
Message-Id: <3.0.6.32.19990906115844.007f5100@mail.intplsrv.net>
Date: Mon, 06 Sep 1999 11:58:44 -0500
To: cypherpunks@algebra.com
From: Sean Roach <roach_s@mail.intplsrv.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: Sean Roach <roach_s@mail.intplsrv.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
No, I am not a cryptographer.
I gave it some thought, in the moments before I went to sleap.
The second encryption over the XORed channel could actually be
necessary.
Since any feed from a human source isn't truly random, a savvy
computer operator watching your line may be able to deduce your key's
signal type based on certain signatures of it's datatype, narrowing
down what to at least attempt to record.
For instance, DirectTV uses MPEG compression to send you all those
nice little channels down a narrower pathway. I haven't done it for
sure, but this is what I envision. If you XOR an MPG with a GIF, you
will have what should look pretty random. If, however, you know that
one half the XOR is a GIF, then you might be able to correct for at
least part of the corruption on the MPG. Since you don't know what
either the MPG or the GIF look like, your left with getting, and
XORing out everything that is common to GIF's.
Hyptothetical example of two datatypes. I know that this is very
basic to a good many of you, but it still hit me as important. And
since I don't know what this type of attack is called, I'm still left
with describing it. Datatype A is the secret communication channel,
and Datatype B is the selected garbage broadcast. And, yes, I just
banged semi-randomly on the keyboard to get this, and yes, I'm
left-handed, which is why there are so many left-side characters.
A
jedvpwfn4dkdo4spc-3verxgerxcgawserxgettfgn2-
B
n8i9dfstwzveredrocfseserv0d;mli84fgbb039u4nv
Now, lets assume that all files of type A start jed and end in - with
either an n, or a 2 preceeding it. Lets also assume that every 16th
character after the 3rd, is similary predictable. Since we know that
the communication is of type A, or at least we can guess, we are
wanting B for later analysis, and trying to determine just what to
record for later use.
If you want a true hash, you can generate it yourself. For my
example I don't really need one.
After taking out those characters which can be predicted, they know
this about the key.
n8i s b nv
or
n8i s b Xv, where the X is a null,
(from XORing n with n.)
Looking at these two possibilities, they may be able to deduce what
type of signal was used as a key, and focus their recording efforts
on media sources which transmit this type of data. As they listen,
the computer they have can continue to prune out the suspect
datastreams until only one needs be recorded in the end.
Therefore, some type of actual encryption needs to be used to make
the final output look more random.
Of course, another problem is, the greater the distance between two
participants, the fewer choices for cover static, and thus, the fewer
signals that need to be recorded in the first place.
On a side note, for experimental purposes, two persons occupying the
same relative position could probably make this work with radio or TV
tuner cards.
Such cards could also be used in the long term, for securing local
communications, where one party doesn't have access to a satellite
feed.
I personally have neither the location, equipment, or experience to
try this.
Sean Roach
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBN9PyxJHDoiHtqFDZEQIoKwCgqi/G3Oxo4Q03+NTAQVvBFfOh1lwAn21O
rFGHLNkXWHQZrm41G4Nxy7DC
=4cDs
-----END PGP SIGNATURE-----
