[118740] in Cypherpunks
Re: Unplugged! The biggest hack in history
daemon@ATHENA.MIT.EDU (Sean Roach)
Thu Oct 7 00:56:18 1999
Message-Id: <3.0.6.32.19991006233815.0084fde0@mail.intplsrv.net>
Date: Wed, 06 Oct 1999 23:38:15 -0500
To: cypherpunks@algebra.com
From: Sean Roach <roach_s@mail.intplsrv.net>
In-Reply-To: <19991006233255.I8045@die.com>
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
At 11:32 PM 10/6/99 -0400, die@die.com wrote:
...
> The trick is to get some kind of directional access to the phone
>line. A tap which merely samples voltage across the pair of wires
>will yield an admixture of the two directions of transmission that
>is very hard to separate out. If one can also sample current
>flowing through the wires at the same time, one can isolate out one
>direction from the other with enough directivity to be able to
>demodulate the stronger of the two signals, especially if it is
>sending the idle LAPM flags pattern. Once one has trained on the
>stronger signal it becomes possible to exactly predict what it
>should be going into the wire and figure out the impulse response of
>the line between the stronger modem and the monitoring point. With
>this, it becomes possible to very precisely predict the contribution
>of the stronger modem to the composite signal and subtract it out,
>yielding the weaker signal.
>
> I suspect that the reason the FBI used a nearby warehouse for
>their interception rather than just running a line to the local FBI
>office was precisely because they needed to access the current
>flowing down the wire by interposing their tap in line with the
>cable between the hacker's house and the CO. The same effect can
>be gotten by taking advantage of the hybrid on the line card of the
>CO switch and getting the switch to ship both directions of the line
>audio to the FBI office in digital format, but this probably
>requires the CALEA modifications to the switch which might not have
>been in place that long ago.
...
This sounds good to me. But my skills with electronics ends at
1/(1/r1 + 1/r2+...), etc.
I was wondering something though. Someone brought up the issue of
two parties with a high level of signal loss, but with the facility
to get replacement packets, being able to keep a third party with far
less signal loss, but without the ability to get replacement packets,
out of a conversation. This same person, if memory serves, mentioned
this same point when I was scheming to use radio chatter as an OTP
for real-time communication to thwart decoding of signals years down
the road.
If the tap is in-line with the communication channel, and if the
computer getting the information is sufficiently fast enough, could
the computer determine that the probability on a packet being
complete was below a certain threshold and intentionally corrupt the
end of that same packet for the receiving computer so that IT would
request a replacement? Perhaps by digitally simulating one of the
myriad real reasons packets get lost? Sort of using what one of us
was saying about the reliability of remailers being compromised on a
peer-to-peer connection. Granted, it would not work at all if the
packet were deemed unsalvegable only after it had been completely
received, but if some determination could be made in advance of the
last bit being sent, then it might work.
Flaws as I see them.
I'm assuming, probably erroniously, that a given packet can be
checked for errors, up to a certain time, where that time is before
the packet has been completely transmitted.
Toying with the connection may tip off the bugged that someone is
evesdropping.
Another idea. What about intentionally degrading the quality of the
line to keep the ratio of hit and miss better in favor of the
evesdropper?
Paranoid thought, and without any technical basis whatsoever. Could
this be the reason, or part of the reason, that 56kbps modems are
limited to a maximum speed that is less than the hardwares
capabilities? I had assumed that perhaps the government has merely
disallowed the use of 2.6MHz.
Sean Roach
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBN/wjtpHDoiHtqFDZEQL+SwCdFhSs5CHujUO8QO3o2n4T6ovR3KAAn11c
eBbu+1kftI6SWBzGfryvJ7wp
=ynf8
-----END PGP SIGNATURE-----
