NODE a19888eaRe: clipper not end of world
Dan Day <dday@houston.geoquest.slb.com>Wed, 27 Apr 94 09:04:35 PDT
> From: Mikolaj Habryn <dichro@tartarus.uwa.edu.au>
> Seems to me, if one is talking about videophone type devices,
> they are transmitting quite a great deal of info, and stegging in a
> message is quite feasible, is it not? You don't even have to do much of a
> hardware modification. Do something like having an HF carrier tone in the
> background, that anyone listening to it can't detect without the knowing
> what they're listenong for. Or insert a microburst transmission - it'll
> look like static.
In one of his novels, James P. Hogan had a clever way to insert
clandestine messages. There was a moon-earth communications link, and
the traffic over the link was monitored to make sure no one was giving
away secrets from the installation on the moon to a mole on the earth
end. The problem was that they were doing the surveillance on the
cleaned-up data stream. The transmission protocol had the
semi-standard error correction, whereby blocks of data were
transmitted, the checksum was calculated and compared, and bad blocks
were thrown away followed by a request for a resend. The spies on the
moon merely contrived to send the occassional "bad block" which
actually contained the message they wanted to piggyback on the
datastream. A listening post monitored the raw data stream and
extracted those "bad blocks" which had the right data signature, and
the hidden messages were stored and decoded. The people checking the
received data which passed the error check never saw the message and
assumed all was well, since their own communications gear had already
editted it out of the data stream.
NODE f7e4be04Re: clipper not end of world
rarachel@prism.poly.edu (Arsen Ray Arachelian)Wed, 27 Apr 94 09:44:23 PDT
About sending bad blocks... if your receiving party can listen in on the
transmission, you could simply change the program for them to include another
checksum somewhere else in the middle of the block. Say, packet a has a bad
checksum, then its a candidate for hidden info.. so you check your secret
checksum. If it matches, you decode the compressed block.
Obviously, your transmitter should send the steggoed data twice due to
possible real errors which would eat your cyphermessage for lunch. Of course
the repeats would have to look different than the originally sent stegoed
packets or else the warden might get suspicious if he decides to have a look
at the bad packets...