<div dir="ltr"><div><div><div><div>Hello Jacek and all,<br><br></div>Before, going down this path I would recommend reading the very relevant works:<br><br><strong><span class="" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rfr_id=info%3Asid%2Focoins.info%3Agenerator&rft.genre=article&rft.date=2005-06-06&rft_id=http://www.cl.cam.ac.uk/%7Esjm217/papers/%23pub-ih05coverttcp&rft.atitle=Embedding+Covert+Channels+into+TCP%2FIP&rft.title=7th+Information+Hiding+Workshop&rft.au=Steven+J.+Murdoch&rft.au=Stephen+Lewis">Embedding Covert Channels into TCP/IP</span></strong><br>
<em>Steven J. Murdoch, <a href="http://www.cl.cam.ac.uk/%7Esrl32/">Stephen Lewis</a></em><br>
It is commonly believed that steganography within TCP/IP is easily
achieved by embedding data in header fields seemingly filled with
“random” data, such as the IP identifier, TCP initial sequence number or
the least significant bit of the TCP timestamp. We show that this is
not the case; these fields naturally exhibit sufficient structure and
non-uniformity to be efficiently and reliably differentiated from
unmodified ciphertext. Previous work on TCP/IP steganography does not
take this into account and, by examining TCP/IP specifications and open
source implementations, we have developed tests to detect the use of
naïve embedding. Finally, we describe reversible transforms that map
block cipher output into TCP ISNs, indistinguishable from those
generated by Linux and OpenBSD. The techniques used can be extended to
other operating systems. A message can thus be hidden in such a way that
an attacker cannot demonstrate its existence without knowledge of a
secret key.<br>
<em><a href="http://www.uoc.edu/symposia/ih05/">7th Information Hiding Workshop</a>, Barcelona, Catalonia (Spain), 06–08 June 2005. Published in <a href="http://www.springerlink.com/content/978-3-540-29039-1/">LNCS 3727</a>, Springer-Verlag.</em>
[ <a href="http://www.cl.cam.ac.uk/%7Esjm217/papers/ih05coverttcp.pdf">paper</a> ]
<br><br></div>and<br><br>John Giffen, Rachel Greenstadt, Peter Litwack, Richard Tibbetts,
<a href="https://www.cs.drexel.edu/%7Egreenie/eecs_files/tcpcovertchannels.pdf">Covert Messaging in TCP</a>,
<a href="http://www.pet2002.org">Privacy Enhancing Technologies (PET), April 2002</a><br><br></div>Best regards,<br><br></div>George<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 4:02 PM, Ian Goldberg <span dir="ltr"><<a href="mailto:iang@cs.uwaterloo.ca" target="_blank">iang@cs.uwaterloo.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jan 07, 2014 at 06:41:02AM -0800, Jacek Wielemborek wrote:<br>
> Hi,<br>
><br>
> I recently had an opportunity to watch David Fifield's lightning talk on<br>
> pluggable transports that he gave on 30C3. I find the topic fascinating and I'm<br>
> considering an application to your project for the upcoming Google Summer of<br>
> Code.<br>
><br>
> My idea is a bit complicated - I'd like to create a pluggable transport that<br>
> hides data in TCP sequence number gaps or UDP source port numbers. I don't yet<br>
> have all details thought over, but the way I imagine it right now, the user<br>
> would have to establish a TCP or UDP connection to the relay. The connection<br>
> could be completely bogus, though it'd be useful if a lot of data was sent<br>
> over it. After connecting, the client sends to the server a message with a<br>
> random RSA key steganographically hidden in the TCP sequence numbers. If the<br>
> server replies the same way with an RSA-encrypted AES key, the rest of the<br>
> hidden transmission goes encrypted with it. Since the SEQ number gaps are<br>
> meant to be random anyway, I believe that this could be very hard to detect.<br>
<br>
</div>Only the initial SEQ of a TCP connection is random (and usually only ~24<br>
bits at that). The subsequent SEQs are deterministic. Can you clarify<br>
your intent?<br>
<br>
- Ian<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div><br></div>