From: Ben Holiday <ncognito@gate.net>
Date: Mon, 11 Mar 1996 05:22:51 +0800
To: cypherpunks@toad.com
Subject: Re: TCP/IP Stego (was CU-SeeMe)
In-Reply-To: <199603082056.MAA20781@netcom7.netcom.com>
Message-ID: <Pine.A32.3.91.960309005518.27482B-100000@seminole.gate.net>
MIME-Version: 1.0
Content-Type: text/plain


Okay, i'm going to try to address things systematically, here goes..
(excuse non standard quoteing)
_______________________

>From savron@world-net.sct.frSat Mar  9 00:54:38 1996

>Fine idea to create a subliminal channel using packet parity on an 
>ftp connection but this is not a peer connection , so can't be used 
>to do subliminal chat (for example) but could be used to do 
>subliminal mail delivery .

------------------------

Since the data is steg'd into the tcp header and not the data you are 
sending (openly) it doesnt make much difference what client is generating 
the packets. Could be a web server. Could be a Y/Ntalk client, a sendmail 
daemon, or a telnet. The greatest restriction being that you only get 
about 1k per 500k .. which is a bit cumbersome in most cases. More on 
that later.

------------------------

>From JonWienke@aol.comSat Mar  9 00:54:43 1996
Subject: Re: TCP/IP Stego (was CU-SeeMe)

>This is a bad idea, because in addition to the extra processor overhead, it
>is an incredible waste of bandwidth.  For a 512 byte packet, you are only
>getting .02% efficiency, because you wouldn't be able to use the actual data
>in the packet; otherwise someone would probably notice the increased error
>rate if you dink around with the checksum.  

No need to do anything strange to the checksum.  In the normal process of 
framing packets data is buffered, and packets are 'padded' to make a full 
packet. The hacked tcp protocol would simply be a bit more selective 
about where and when padding was added. The checksum would still be a 
valid checksum for that packet - we would simply select a packet that gave 
a correct checksum value. The overhead for this is more than with 
standard tcp but could hardly be considered a serious drain of cpu cycles.

As for wasted bandwidth: That could be seen as a problem, but there are a 
few things to offset the overhead, the big one being that it doesnt make 
any difference what form the carrier data takes.. if you can generate 
half a meg of ANYTHING that can be plausibly sent to another machine, 
then you can send your 1k of data. If implemented properly the carrier 
data wouldnt even need to all come in through the same route. This 
scenario leaves any one who may be watching with quite a haystack, and a 
very small needle to find.

>This does not provide adequate plausible deniability.  Stegoing a 16 bit 

I disagree. Consider: the packet, taken bit by bit, or as a whole, 
would be completely valid - with nothing added, or taken away except 
perhaps the few octets that would need to be dropped to acheive the right 
parity. This would actually be very few, since you have a 
50% chance that the parity will be correct to begin with. 

---------------------

From: Jim McCoy <mccoy@communities.com>
Subject: Re: TCP/IP Stego (was CU-SeeMe)


>I think that the original poster meant twiddling some of the (relatively)
>unused fields of the header which most routers and applications do not
>care about, the type-of-service field or priority would good place to
>start.  

I'm pretty certain that altering TOS would pretty well scrap the packet, 
but im not positive. <shrug>. Sequence numbers are definitly out. However 
i think that playing with the priority flag could definitly work. Also a 
parity check of the 'window' field could be done quite easily. Only 
problem i see is that 'priority' packets basically are only used for 
special characters and the like, for example to send 'ctrl-c' to a 
abort a running ftp. Having a large number of priority packets would be 
reletivly noticable. The window field is a bit more promising - you'd 
need to prove the arrival sequence and timing of each packet and ack in the 
stream to prove that it had been tweaked.

>This would have no effect on the data in the packet, particularly
>if you fiddle at the IP level instead of TCP.  
[tons of good things I hadnt even thought of snipped]

--------------------

From: Bill Frantz <frantz@netcom.com>
Subject: Re: TCP/IP Stego (was CU-SeeMe)

>If you can hack your TCP implementation, you should be able (with a high
>probability) stego information in a few bits of the TCP checksum by
>adjusting the packet boundries of the TCP stream.  An error correcting code
>protocol would cover the cases where you couldn't get that *%$# bit set
>correctly.  Please note that this technique would not result in TCP
>checksum errors.

Thank you! This is what I was attempting (apparantly quite poorly) to say 
in the original post. 

:) 

Benji